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Vorwort 


Vorweg, ein paar Grüße an ! 


Hans Peter, denk an unsere 8 Bit Zeiten ! 

Biggi, lerne über Deinen Schatten zu springen ! 

Jörg M., gib ihr noch eine Chance ! 

Katja, I O U (seriously) 

Thomas, to be in England.... 

und 

Klaus, Matthias, Stefan, Jörg, Daniel und Diana, Axel, Maren 
Oliver, Arne und Marcus (Amiga Freaks), Gert, Christine, 
noch ’ne Katja, Sonja, Virginia, Xiaoping, Robert (PC Freak), 
Regina, u.v.m. 

meine Komilitonen vom Studiengang AI in der FH- Frankfurt 
"bitte nicht böse sein , wenn ich jemand vergessen habe!" 

ATARI, viel Glück für euren Falcon030 !!! 

"and may the force be with you" 

Vielen Dank an ! 

Kay, Torsten und Simon 

Die Konstrukteure des ATARI 520ST, für das gute Bus-Timing ! 

Die Konstrukteure der ATARI 400/800 Computer!!! 

Die Demoprogrammierer auf dem AMIGA, weil ihre Demos immer 
neue Herausforderungen brachten. 
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Viele Produkte und Warenzeichen, die ich in diese Buch verwende, sind geschützt 
und daher Eigentum der jeweiligen Firmen. 

Dieses Buch ist mit größter Sorgfalt erstellt worden, jedoch können Fehler immer passieren, 
deshalb übernehme ich keinerlei Garantie für eventuelle Schäden durch Nutzung von Program¬ 
men und Informationen aus Buch oder Diskette. 
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Vorwort 


Vorwort 

Vor etwa zehn Jahren hat ein Computer mit der Leistungsfähigkeit 
eines ATARI ST noch mehr als 20000 Mark gekostet. Als ich Ende 
1985 mir meinen ersten ST kaufte, galt der Motorola 68000 noch 
als sehr schneller Prozessor. Ich war zu dieser Zeit von meiner 8 
Bit Maschine, einem ATARI 400/48K in Sachen Geschwindigkeit 
noch nicht so sehr verwöhnt. Mein ST hat mich zu dieser Zeit sehr 
oft durch seine Leistungsfähigkeit erstaunt, um allen die so wie ich 
damals heute umgestiegen sind, einen all zu großen Schock zu er¬ 
sparen, möchte ich Ihnen jetzt schon mitteilen, daß man Spiele, die 
z.B. auf dem C64 in Maschinensprache geschrieben worden sind 
auf dem ATARI ST auch in BASIC programmieren kann ! Die ST 
Computer sind mittlerweile in Preisregionen gefallen, in denen man 
auch reine Videospielgeräte findet; doch der ATARI ist mehr. Er 
ist nicht nur eine gute Videospielkonsole sondern ein komfortables 
Textverarbeitungssytem, mit dem man auch ohne Festplatte ange¬ 
nehm arbeiten kann, er ist DTP - Center, kann messen, steuern 
und regeln und ist eine Hilfe für jeden Profimusiker, auch konstru¬ 
ieren, zeichnen und vieles mehr ist mit ihm möglich. Er ist fast viel 
zu schade nur zum Spielen, außer man realisiert auf ihm die eige¬ 
nen Ideen und Wünsche. Um Ihnen zu zeigen wie einfach das geht, 
und um zu zeigen, daß der ATARI ST immer noch ein geniales Ge¬ 
rät ist, auf dem zweitklassige Umsetzungen von Spielen nicht nötig 
sind, habe ich dieses Buch geschrieben. Dieses Buch richtet sich 
somit sowohl an den interessierten Neuling wie auf den fortge¬ 
schrittenen Programmierer, und nicht zuletzt ist dieses Buch als 
Nachschlagewerk gedacht, das dem Programmierer von anderen 
Rechnertypen die Konvertierung ihrer Spiele erleichtern soll. 
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Teil I: Einführung in die Spieleprogrammierung 

Die phantastische Einbildung ist zugleich praktische Zauberin, wird 
in dem unaufhörlichen Wechselspiel zwischen Phantasie und Idee, 
zwischen Affektivität und Praxis zur Quelle aller denkbaren Innova¬ 
tionen, welche die menschliche Evolution vorangetrieben und berei¬ 
chert haben. 

Aus, "Das Rätsel des Humanen", von Edgar Morin. 

Immer wieder werde ich von irgendwelchen "Kids“ besucht, die mit 
ihrem Computer nichts anderes anzufangen wissen, als einschal¬ 
ten, Spiele laden, ausschalten. Doch gelegentlich ist der Eine oder 
Andere dabei der mich fragt, "Wie funktioniert die Kiste, und wie 
kann ich selbst Spiele schreiben ?“. Da es meiner Meinung nach 
(bis jetzt) für die ATARI Rechner noch kein brauchbares Buch zu 
diesem Thema gibt und ich nicht jedem persönlich zeigen will (und 
kann) wie man Spiele programmiert, habe ich dieses Buch ge¬ 
schrieben. 


Don’t Partie !!! 
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Eine kurze Einführung in die Arbeitsweise des Computers 

Heutige Computer bestehen aus Eingabegeräten wie: 

- Tastatur - Scanner - Joystick - Maus - CD ROM 

und aus Ausgabegeräten wie 

- Bildschirm - Drucker - Plotter u.v.m. 


und Geräten die beides können 

- Diskettenlaufwerke - MOD Laufwerke - Festplatten ... 

bei einigen Computern ist das meiste schon im Gehäuse integriert, 
bei den Atari Computern meistens nicht. 

Was noch fehlt, ist eine Einheit, die diese Ein/Ausgabegeräte steu¬ 
ert. Diese Einheit besteht bei den ATARI Computern aus einer 
CPU, je nach Gerät ein MC 68000/010/020/030, "etwas" Speicher 
und einigen Chips, die die Kommunikation mit den entsprechenden 
Geräten erst möglich machen (sogenannte Peripheriebausteine). 

Die CPU (Central Processing Unit, d.h. zentrale Verarbeitungs- 
Einheit) ist das Herz eines jeden Computers. Sie führt die Befehle, 
die im Speicher stehen, aus. Wenn man einen ATARI ST einschal¬ 
tet, springt die CPU automatisch über einen Zeiger, der am Anfang 
des "Speichers" steht (dazu später mehr), zu einem nichtflüchtigen 
Speicherbereich und führt dort schon sein erstes Programm 
aus, bei den meisten Rechnern ist es das sogenannte BIOS (oder 
Kernel), bis Anfang 1986 galt das auch für den ST, denn seit April 
1986 liefert Atari seine Computer mit einem "fast" kompletten Be¬ 
triebssystem aus. Der nichtflüchtige Speicherbereich ROM 
(Read-Only-Memory, Nur-Lese-Speicher) erhielt seinen Namen, 
weil er vom Prozessor nur gelesen aber nicht verändert werden 
kann. Nichtflüchtig ist er, weil er nach dem Ausschalten seinen In¬ 
halt behält. Das ist auch gut so, da sich nach dem Einschalten des 
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Rechners im RAM (Random Access Memory, Speicher mit wahl¬ 
freiem Zugriff) "Müll" befindet, d.h. der Inhalt des Speichers enthält 
zufällig irgendwelche Daten - der Prozessor würde kein ausführba¬ 
res Programm finden, was einen Systemcrash (totalen Absturz des 
Computers) zur Folge hätte. Übrigens, der Zugriff auf das RAM ist 
“wahlfrei“, weil man es sowohl beschreiben als auch lesen kann. 


Nun, aber was ist überhaupt Speicher ? 

Speicher kann man sich als eine Straße vorstellen. Jedes Haus hat 
eine Hausnummer, ein Haus entspricht einem Byte, zwei gegen¬ 
überliegende Häuser (eins mit gerader Hausnummer und eins mit 
ungerader) nennt man Wort und zwei Wörter ein Langwort. So ist 
es zumindest bei den Motorola Prozessoren. Aus dem Informatik- 
Studium weiß ich, daß das Wort eine Hardware (Prozessor) Eigen¬ 
schaft ist, d.h. es gibt für andere Prozessoren auch größere oder 
kleinere Worte. Die Hausnummer nennt man Adresse. Viele Pro¬ 
zessoren können viel mehr Speicher adressieren (verwalten) als 
die Computer beinhalten, in dem sie stecken. Der 68000er kann 
z.B. 16,7 Millionen Bytes adressieren. Im Atari werden aber meist 
nur 1 MB RAM und 192KB ROM davon genutzt. Übrigens, 1 MB 
bedeutet 1024*1024 Bytes und 1 KB sind 1024 Bytes. Jedes Byte 
ist in 8 Bit (Blnari DigiT, binäre Einheit) unterteilt; jedes Bit kann 
man sich als einen Schalter vorstellen, der zwei Zustände (an & 
aus) annehmen kann. Ist einer dieser Schalter mit einem "Periphe¬ 
riebaustein" verbunden, kann das Setzen dieses Bits (einschalten) 
z.B. die Hintergrundfarbe des Bildschirms oder die Bildwiederhol¬ 
frequenz ändern. 
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Was macht also ein Programm ? 

Ein Programm ist also nichts anderes als eine Menge von gesetz¬ 
ten und gelöschten Bits, die der Prozessor schrittweise (z.B. 16 
Bit) abarbeitet. Diese Bits interpretiert der Processor als Befehl, 
der ihn z.B. das Bit eines Hardwareregisters (Speicherstelle eines 
Peripheriebausteins) setzen oder löschen läßt. Die CPU kann aber 
auch einen Teil in einen anderen Teil des Speichers kopieren, In¬ 
halte von Speicherstellen addieren, subtrahieren, multiplizieren und 
andere schöne Sachen. Näheres dazu finden sie im Kapitel über 
die Einführung in die Maschinensprache. 


Wozu braucht man dann das Betriebssystem ? 

( "das fragen sich viele gute Demoprogrammierer auch ") 


Das Betriebssystem ist ein Programm, das sich im ROM befindet. 
Es ist eine Sammlung von Funktionen, die (meistens) sehr einfach 
aufzurufen sind. Es sind Funktionen wie z.B. das Laden eines Sek¬ 
tors von Diskette oder das Zeichnen einer Linie zwischen zwei 
Punkten. Man sollte diese Funktionen (wenn möglich) nutzen, denn 
nur so kann man sicherstellen, daß ein solches Programm auch auf 
den ATARI Rechnern der nächsten Generation z.B. dem TT oder 
Falcon ohne Probleme seinen Dienst verrichtet. Zum Thema Be¬ 
triebssystem sollte man nicht vergessen, daß die Annehmlichkei¬ 
ten, wie es das Desktop des Ataris bietet, ein Teil des Betriebssy¬ 
stems sind, welche ab TOS 2.0X auch wirklich als angenehm emp¬ 
funden werden können (allen anderen empfehle ich Programme wie 
die GEMINI Shell). 
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A.l. Kurze Einführung ins GFA - BASIC 

Ich habe GFA-BASIC als "Lernsprache" gewählt, weil dieser 
BASIC Dialekt sowohl flexibel in seiner Anwendung und leicht er¬ 
lernbar ist als auch strukturiertes Programmieren unterstützt. 

Um die Technik der Spieleprogrammierung zu erlernen, möchte ich 
die grundlegenden Techniken in einer einfach zu erlernenden Pro- 
gammiersprache vermitteln. Diese Sprache nennt sich BASIC. 
BASIC ist eine Hochsprache, so wie z.B. C, Modula, Forth, 
FORTRAN , PASCAL. 


Was ist eine Hochsprache ? 

Es gibt zwei verschiedene Arten von Hochsprachen, es gibt Inter¬ 
preter Sprachen und Compiler Sprachen und natürlich Ausnahmen, 
die beides sind, wie z.B. GFA-BASIC. Eine Compiler Sprache be¬ 
steht meist aus einer Entwicklungsumgebung mit einem Editor, ei¬ 
nem Compiler mit Linker und einer Shell (ein Programm zum Star¬ 
ten des Editors oder Compilers, mit gleichzeitigem übergeben von 
Dateinamen und anderer Optionen). Ein Editor ist eine abgespeckte 
Textverarbeitung, in die man den Programmtext eintippt. Dann 
speichert man den Text auf eine Diskette und ruft den Compiler 
auf. Der Compiler wandelt den Programmtext in ein ausführbares 
Programm. Bei einer Interpretersprache hat man in den meisten 
Fällen einen Editor mit gleichzeitiger Syntaxkontrolle, d.h. nachdem 
man eine Zeile mit Befehlen eingegeben hat, testet das Programm, 
ob er die eingebenen Befehle kennt und gibt sofort eine Fehlermel¬ 
dung aus. Das ist allerdings der Idealfall; viele Interpreter geben die 
Fehlermeldungen erst nach dem Start des Programms aus. Nach¬ 
dem man dann das Programm vollendet hat, kann man es sofort 
starten, vorausgesetzt, es hat keine Strukturfehler. 
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Nun, was macht die Hochsprache aus den Befehlen ? 

Eine Compiler wandelt den Text, den man mit dem Editor erstellt 
hat, in Maschinensprache um, allerdings ist das nur so eine Art 
"Ablaufplan“ und der Linker verbindet diesen "Ablaufplan" mit den 
entsprechenden Progammteilen einer Bibliothek. (Das ist nur eine 
grobe Darstellung, die ich später noch weiter erläutern werde.) Bei 
der Ausführung des Programms werden die Programmteile der Bi¬ 
bliothek von dem "Ablaufplan" aufgerufen. Beim Interpreter muß 
das Programm Befehl für Befehl übersetzt und die entsprechenden 
Funktionen aufgerufen werden. Natürlich kostet das Übersetzen et¬ 
was Zeit, auch kann ein Compiler, weil er mehr Zeit zum Überset¬ 
zen hat, effektivere Programme erzeugen, so daß eine Compiler¬ 
sprache in der Regel schneller ist als das interpretierte Pendant. 


Was ist denn so ein Programm ? 

Ein Programm ist ein Algorithmus, d.h. eine Arbeitsanweisung, 
die in eine Computersprache (und damit vom Compiler oder Inter¬ 
preter in Maschinensprache) umgewandelt wird. 


Was ist ein Algorithmus ? 

Ein Beispiel: 

Algorithmus zum Öffnen einer Tür 

1. Gehe zu Tür 

2. Drücke Klinke herunter 

3. Ziehe Tür an der Klinke in Richtung Wand 

mehr zum Thema Algorithmus finden sie in div. Büchern, die die 
Einführung in die Informatik behandeln. 
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Ein einfaches Spiel mit Linien und Kreisen 

Es ist extrem einfach in GFA - Basic Linien und Kreise zu Zeichen. 
Die Befehle dazu sind: 

Line ax,ay,ex,ey 

Wobei die ersten beiden Werte ax/ay den Anfangspunkt angeben, 
von dem aus die Linie gezeichnet werden soll und ex/ey den Punkt 
angibt, zu dem die Linie gezeichnet werden soll. Die linke obere 
Ecke des Bildschirms ist der Punkt (0,0) und die rechte untere Ek- 
ke in der niedrigen ST Auflösung (319,199). Diese Werte stimmen, 
solange sich keine Hardwareerweiterungen wie Overscan, Hy- 
perscreen oder Pixel Wonder in Ihrem Atari befinden. Falls das 
doch der Fall sein sollte, kann die rechte untere Ecke durchaus hö¬ 
here X- und Y-Werte aufweisen. 

Circle ax,ay,r 

I I I_ Radius 

I I_ Vertikale Position (X - Position) 

I_ Horizontale Position (y - Position) 

Der Befehl Circle zeichnet einen Kreis. 

(ähnl. wie ein Zirkel, den man in der Realität dazu benötigt) 

Pellipse ax,ay,rx,ry, <--- wil ,wi2 optional (bei bedarf) 

INI I I_ Winkel 1 in 1/10° 

I I I I I_ Winkel 2 in 1/10° 


I I I_ senkrechter Radius 

I I_waagerechter Radius 

I_ Anfangspunkt Y 

_ Anfangspunkt X 


mit dieser Funktion kann man Kreissegmente und Ellipsen erzeu¬ 
gen, wenn man wil und wi2 setzt (Anfangs u. Endwinkel). 
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Box ax,ay,ex,ey 

I I I I_ senkrechte Endposition 

I I I_ waagerechte Endposition 

I I_ senkrechte Anfangsposition 

I_ waagerechte Endposition 


Wenn man jeweils ein ’P’ vor die Zeichenfunktionen schreibt wie 
Pellipse / Pcircle / Pbox, werden die jeweiligen Körper ausgefüllt. 

Diese Befehle sind GFA-BASIC spezifisch, rufen jedoch interne 
Funktionen des Betriebssystems auf. Nähere Informationen über 
diese Befehle entnehmen Sie Büchern über GFA-BASIC, GEM 
(Graphics Enviroment Manager - Verwalter der Grafischen Ober¬ 
fläche) und/oder VDI. 

Nun sollten Sie mit den Funktionen etwas herumprobieren. Außer¬ 
dem die auf der Diskette befindlichen Listings (Programme im 
Quellcode - also in Worten) LINE.LST / CIRCLE.LST / BOX.LST 
ausprobieren. Diese werden mit der Funktion MERGE des Inter¬ 
preters eingeladen, (auch mit der Taste F2 zu erreichen) 


Wie kommt das Bild auf den Schirm ? 

Der Video-Chip, der Chip, der das Bild erzeugt, tastet "ununterbro¬ 
chen" einen Teil des Speichers ab, den sogenannten Bildschirm¬ 
speicher oder Video-Ram. Dieser wird vom Prozessor oder dem 
Blitter (einem speziellen Chip der Speicherinhalte kopieren und da¬ 
bei mit anderen Speicherbereichen verknüpfen kann) beschrieben, 
je nach Inhalt dieses Speicherbereiches und der Einstellung des Vi¬ 
deoprozessors, sieht das was wir auf dem Monitor betrachten kön¬ 
nen wieder ganz anders aus. Dazu mehr im zweiten Teil des Bu¬ 
ches Kapitel B.1 
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Vorbereitungen für unser erstes Spiel! 

Unser erstes Spiel heißt 'Ball gegen die Wand“, es ist ein - zugege¬ 
ben - recht einfaches Spiel, das man aber vor einigen Jahren in 
ähnlicher Form noch als Spielautomat antreffen konnte. 

Steuerung: 

Dieses Spiel läßt sich am besten mit der Maus oder einem Paddle 
steuern. Da ja nicht jeder ATARI ST-User ein Paddle besitzt, habe 
ich mich für Maussteuerung entschieden. 

Dazu stellt uns GFA - BASIC die Befehle 

Mousex, Mousey und Mousek zur Verfügung, 

Ein kleines Programm veranschaulicht die Funktion der Befehle. 

color 1 ! Zeichenfarbe 

Repeat ! Wiederhole 

Plot Mousex, Mousey 

Until Mousek=1 ! Bis LinkeMaustaste gedrückt 

Dieses Programm zeichnet an der Stelle, wo sich der Mauspfeil 
befindet, einen Punkt. Beim Drücken der linken Maustaste wird das 
Programm beendet. Das ist sehr wichtig, da man Programme so 
schreiben sollte, daß man sie regulär verlassen kann, regulär heißt 
ohne Reset oder Ausschalter. Der Interpreter bietet allerdings auch 
die Möglichkeit, mit den Tasten [Control] [Shift] [Alternate], alle drei 
gleichzeitig gedrückt, das Programm zu verlassen. 
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Die Sache mit den Schleifen ! 

Repeat <-— Anfang der Schleife 


Until Mausek=1 <---- Ende der Schleife 

( A ) I 

I--- Bedingung die nicht!!! erfüllt sein darf, 
damit die Schleife wiederholt d.h. vom 
Anfang bis zum Ende noch einmal !!! 
durchlaufen wird. 

Was man sich dabei merken muß ! 

Eine Schleife dieser Art, d.h. das Innere der Schleife, wird minde¬ 
stens einmal durchlaufen ! 

Eine solche Schleife nennt man oben offene Schleife, weil bei der 
Programmausführung die Schleife "auf jeden Fall” von oben betre¬ 
ten und hoffentlich auch irgendwann wieder verlassen wird. Eine 
Schleife, die nicht verlassen wird (niemals, außer man betätigt den 
allmächtigen Reset oder verhindert die Stromzufuhr - wie schon 
erwähnt), nennt man Endlosschleife. 

Es gibt jedoch von oben abweichende Schleifen, 

hier ein Beispiel: 

while mousekol <— Anfang der Schleife 

( A ) 

I 

I_Bedingung welche erfüllt sein muß 

damit die Schleife mindestens einmal 
durchlaufen wird 


wend <— Ende der Schleife 
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Es kann durchaus passieren, daß eine solche Schleife, während 
das Programm abgearbeitet wird, niemals durchlaufen wird und nur 
in ganz speziellen Situationen das Innere einer solchen Schleife 
überhaupt ausgeführt wird. 

Es fehlt jetzt nur noch ein Befehl, um auf Änderungen von be¬ 
stimmten Werten zu reagieren. 

repeat 

IF mousek=0 

print “DIE MAUS IST TOT“ 

eise 

print "DIE MAUSTASTE ist gedrückt" 
endif 

until inp(-2)=-1 
if mousek=0 

A A 

I I_Bedingung erfüllt 

I_Wenn 

eise <-sonst 

Endif <-Ende 

Die “Entscheidungsanweisung" ’if ’then’ ’else' ist ein grundlegendes 
Konstrukt vieler Hochsprachen d.h. es ist eine Befehlskombination, 
die wirklich wichtig ist und so oder so ähnlich auch in Pascal 
und/oder C (fast überall) Anwendung findet. 

Nun zur Erklärung: 

Nach ’IF’ folgt eine Bedingung (z.B. Mousek=0), falls diese Bedin¬ 
gung wahr ist, (d.h. erfüllt ist - in diesem Fall, keine Maustaste ge¬ 
drückt worden ist) werden die darunter stehenden Befehle bis zu 
einem möglichen ’Else’ Befehl ausgeführt. Wenn die Bedingung je¬ 
doch nicht erfüllt ist (also ’Mousek’ den Wert 1,2 oder 3 hat, also 
eine Maustaste gedrückt ist) dann werden die Befehle ab einem 
möglichen Else oder einem Endif abgearbeitet. 
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GFA-BASIC, enthält natürlich noch einige Befehle mehr, doch das 
Erläutern dieser Befehle würde den Umfang des Buches sprengen 
und das angestrebte Ziel verfehlen. Wer jedoch Intresse an einer 
Einführung in GFA-BASIC hat sollte sich ein entsprechendes Buch 
(siehe Anhang) kaufen. Jedoch müßte man mit der Bedienungsan¬ 
leitung zu GFA-BASIC und diesem Buch auskommen können. 

Außer Befehlen besteht eine Programmiersprache noch aus ande¬ 
ren Dingen. 

z.B. Operatoren 

Beispiele: 


V 

plus 

zur 

Addition 

(dazu zählen) 

J > 

minus 

zur 

Subtraktion 

(abziehen) 

1*1 

mal 

zur 

Multiplikation 


V 

geteilt 

zur 

Division 



u.v.m 

Vergleichsoperatoren (die wichtigsten) 

’=’ gleich 
’<>’ ungleich 
’>’ größer als 
’<’ kleiner als 
’>=’ größer gleich 
’<=’ kleiner gleich 
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oder Variablen 

Variablen sind einigen Lesern schon aus der Mathematik bekannt, 
es sind Platzhalter für bestimmte Zahlen. Da der Computer jedoch 
nicht unbegrenzt große Zahlen darstellen kann, gibt es in Basic 
verschiedene Arten von Zahlen mit denen der Rechner verschieden 
schnell rechnen kann. 

Variablen bestehen aus mindestens einem Buchstaben 
z.B. ’a' oder ’b’ 

oder mehr Buchstaben z.B. 'zahl’, 'Wort','tausche'. 

Variablen, die nur aus einem Buchstaben bestehen, sind Fließkom¬ 
ma-Variablen (Float - abkürzung für floating Point). Fließkomma- 
Variablen sind Variablen welche Dezimalbrüche (’Kommazahlen’) 
darstellen können. Sie benötigen 8 Byte Speicher und können Zah¬ 
len in einem Bereich von 2.225073858507*10-308 bis 
3.595386269725*10+308 darstellen. 

Wenn hinter dem Namen der Variblen noch ein Zeichen wie: 

! Boolean - kann nur die Werte 0 (False) oder -1 (True) 
annehmen, benötigt 1 Byte 
I Byte - Werte von 0 bis 255 möglich 
benötigt 1 Byte 

& Wort - Werte von -32767 bis +32768 möglich 
benötigt 2 Byte 

% Integer - Werte von etwa +/- 2 Giga 
# Float - siehe oben 
$ Stringvariable - enthält Buchstaben 

steht, benötigt der Rechner unterschiedlich viel Speicher und ver¬ 
arbeitet diese unterschiedlich schnell (Faustregel, je weniger Spei¬ 
cher - desto schneller). 
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Wie benutzt man nun die Variablen ? 
Fast wie in der Mathematik, 


Z.B. a%=a%+1 

auch möglich ’INC a%’ (INCrementiere d.h. erhöhe) 
erhöht den Inhalt von a% um eins 

oder n%=5 

c%=10 
l%=n%+c%*2 

1. Zeile: n% bekommt den Wert 5 

2. Zeile: c% bekommt den Wert 10 

3. Zeile: c% wird mit 2 multipliziert und das Ergebnis zu n% ad¬ 

diert und dann in 1% geschrieben 

1% enthält als Ergebnis die Zahl 25 
auch möglich 

’ADD v%,10' ;erhöht den Inhalt von v% um 10 
’ADD’ steht für "ADDiere" also ’+’ 

oder 


a$=‘Spiele - * 

b$="programmieren“ 

a$=a$+b$ 

Als Ergebnis enhält a$ die Zeichenkette (’ne Menge Buchstaben) 

'Spiele - programmieren’ 

Auch wenn Sie jetzt nicht alles verstanden haben, wird Ihnen das 
meiste wohl bei den Kommentaren zu den Listings bewußt werden ! 
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1.1 Das erste Spiel 

Ist auf der Diskette zum Buch in ’KAPAI.TOS’ unter dem Namen 
’FIRST.LST zu finden. 

Das Spiel ist auflösungsunabhängig programmiert (!), d.h. es fragt 
zuerst im ’work_out Feld’ des VDI (Teil des Betriebssystems der 
für die Bildschirmausgabe zuständig ist) nach, welche maximale 
horizontale und vertikale Auflösung möglich ist und schreibt diese 
Werte in die Wortvariablen ’xmax&’ u. ’ymax&’ 

In etwa so! 

xmax&=WORK_OUT(0) 

ymax&=WORK_OUT(1) 

Danach wird das Unterprogramm ’aufbau’ aufgerufen, das eine Box 
mit maximalen Bildschirmausmaßen zeichnet und die Bildschirm¬ 
ausgabe auf ’XOR’ (eXklusiv OdeR) umschaltet. Das bedeutet, 
wenn man einen Punkt mit einer bestimmten Farbe zeichnet und 
dann mit derselben Farbe darüberzeichnet, wird der zuerst ge¬ 
zeichnete Punkt wieder gelöscht. 

GRAPHMODE 3; schaltet auf XOR 

Wahrheitstabelle: 


A 

1 B 

1 XOR 

0 

1 0 

1 0 

0 

1 1 

1 1 

1 

1 0 

1 1 

1 

1 1 

1 0 
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Hier die Wahrheitstabelle von ’XOR’, die bei der Grafikausgabe auf 
duo/monochromen Bildschirmauflösungen genau mit gesetzten T 
und gelöschten ’0’ Bildpunkten übereinstimmt, wobei ’A’ dem zu 
zeichnende Punkt und B dem Bildschirminhalt entspricht (es geht 
auch umgekehrt) und unter ’XOR’ die dann auf dem Bildschirm 
sichtbaren Punkte wären. 

Wichtig ist noch zu wissen, wie ~das mit der Bewegung des Balls 
funktioniert! 

’ ********* Links und Recht für den Ball ******* 

ADD xb&,nx& 

ADD yb&,ny& 

IF nx&=2 

IF xb&>xmax&-10 ! Wenn Ball rechts angekommen 
nx&=-2 
ENDIF 
ELSE 

IF xb&<10 ! Wenn Ball links angekommen 
nx&=2 
ENDIF 
ENDIF 

’ *************** p ast ( ^ as g| e i c h e fy r dj e y Richtung ****** 

IF ny&=2 

IF yb&>ymax&-10 ! Wenn Ball am unteren Rand angekommen 
init 

ENDIF 

ELSE 

IF yb&<10 ! Wenn Ball am oberen Rand angekommen 
ny&=2 
ENDIF 
ENDIF 

Eigentlich ganz einfach: Wenn ’xb&’ oder ’yb&’> die Variablen für 
den Mittelpunkt des Balls (Kreis), oben bzw. unten angekommen 
sind, wird die Variable ’nx&’ bzw. ’ny&’ in positiv bzw. negativ, so 
daß aus der ’ADD’ition eigentlich eine ’SUB’traktion wird und der 
Ball seine Richtung ändert, da ’nx&’ bzw. ’ny&’ die Variablen sind, 
die die Schrittweite der “Flugbewegung 11 des Balls angeben. Natür¬ 
lich springt der Ball, wenn er ganz unten ankommt, nicht nach oben 
sondern das Programm beginnt von vorn. 
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Mit dem Betätigen der Taste ’Q’ für ’quit’ verläßt man das Pro¬ 
gramm. 

UNTIL BCLR(INP(2),5)=81 iverlasse Schleife, wenn Taste = "Q" 

wobei das ’BCLR(INP(2),5)’ den ASCII - Code der eingegebenen 
Tasten jeweils (falls es Buchstaben sind) durch Löschen des Bit 5 
in Großbuchstaben umwandelt, da ’BCLR’ (Bit CLeaR) lösche Bit 
bedeutet. 

BCLR(xl, yl) 

I I 

I I_0 bis 31 

I 

I_Größe bis Langwort 

bedeutet, daß das Bit yl im Operanden xl gelöscht werden soll. 

Man könnte das Programm noch auf vielfältige Weise erweitern, 
versuchen Sie doch ein kleines Breakout bzw Arkanoid daraus zu 
machen, in dem sich mit ’BOX’ noch einige Vierecke auf den Bild¬ 
schirm zeichnen lassen und diese, wenn sie getroffen wurden, 
wegzeichnen. 
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A.2.16 Farbige Softwaresprites 

Einleitung 

Nachdem wir im letzten Kapitel gesehen haben, wie man mit Krei¬ 
sen und Linien Spiele macht, möchten wir (zumindest ich) natürlich 
auch mal ein paar hübschere Objekte, wie wir es von professionel¬ 
len Spielen gewöhnt sind, auf den Rechner bringen. 

Diese mehrfarbigen Objekte, die scheinbar unbeeindruckt vom Hin¬ 
tergrund sich hin und her bewegen, nennt man Sprites. 

Im Gegensatz zum Amiga, Atari XL, C64, also all jene Computer, 
die eigentlich vorrangig als ’Spielcomputer’ konstruiert wurden, 
kann die ATARI ST(E)/TT/F030-Serie keine Hardware-Sprites, d.h. 
Objekte, die wirklich unabhängig vom Bildschirm, auf dem sie sich 
bewegen, das bedeutet, daß sich das Objekt nicht im Bildschirm¬ 
speicher befindet, darstellen. 

Das bedeutet allerdings nicht, daß man keine Bilder darstellen 
könnte, bei denen es den Anschein hat, das Objekt bewege sich 
ohne Einfluß auf dem Hintergrund. 


2.1 Die Theorie dazu ! 

2.2.1 Was ist ’page flipping’ ? 

Wenn man es weiß, ist es eigentlich ganz einfach (wie alles bei der 
Spieleprogrammierung). Der Bildschirmspeicher, den der Videos- 
hifter darstellt, darf sich fast überall im Speicher befinden (beim TT 
gilt das nur im ST-RAM). Der Trick’ besteht einfach darin, das Bild 
in einem Teil des Speichers aufzubauen und währenddessen ein 
Bild, das sich im anderen Teil des Speichers befindet, darzustellen, 
d.h. der Videoprocessor zeigt einen Speicherbereich an, während 
der Prozessor oder Blitter den anderen beschreibt. Würde man kei- 
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nen anderen Speicherbereich anzeigen, könnte man sich ansehen, 
wie der Prozessor das Sprite mit dem Bildschirm verknüpft (zu¬ 
sammenrechnet). Die Technik der wechselnden Bildschirme nennt 
man ’page - flipping’ (ein bezeichnender Name !). Man kann es sich 
wie beim Daumenkino vorstellen, wobei der vom Videoprozessor 
(Shifter) dargestellte Speicherbereich, den Seiten des bemalten 
Blocks entspricht. Um Speicher zu sparen, benutzt man bei der 
Spieleprogrammierung nicht für jede 'Seite des Daumenkinos’ ein 
neues Stück Speicher, sondern benutzt zwei oder drei Bildschirm¬ 
speicher, welche man wechselt und in einem der gerade nicht dar¬ 
gestellten Speicherbereiche eines der nächsten Seiten aufbauen 
läßt. 


2.1.2 Der Aufbau der Seiten erfolgt meist in 
folgender Reihenfolge: 

□ Zurückschreiben des geretteten Hintergrunds (siehe nächster 
Punkt) 

□ Retten des Hintergrundes 

Beim Retten des Hintergrundes wird dieser an den Stellen ge¬ 
rettet (in einen Puffer, ein Teil des freien Speicher, geschrie¬ 
ben), an denen später die Sprites zu sehen sind. Man kann na¬ 
türlich auch den kompletten Hintergrund in einen Puffer kopieren 
und dann die Teile des Bildes, die man mit den Sprites über¬ 
schrieben hat, wieder zurückkopieren. 

□ Kopieren der Maske auf den Bildschirm 

Die Maske besteht meist nur aus einer Bitplane (aus einem "Bil- 
schirmspeicher“ mit nur einer Farbe). Diese wird mit der Funkti¬ 
on 'AND' (eine Art der Verknüpfung) auf den Bildschirmspeicher 
kopiert (im Kapitel über die Assemblersprache, werde ich die 
Verknüpfungsarten erklären). Dabei wird jede Bitplane so oft 
kopiert wie das Zielbild Bitplanes (z.B. 16 Farben 4 Bitplanes - 
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den 2 hoch 4 ergibt 16) hat. Wenn man Betriebssystemfunktio¬ 
nen zum Kopieren nutzt, kann es helfen, alle Bitplanes auf ein¬ 
mal zu kopieren, was jedoch einen größeren Speicherbedarf für 
die Maske bedeutet z.B. bei 16 Farben 4 mal so viel Speicher. 
Da man die Maske aber leicht errechnen kann, fällt das in vielen 
Fällen nicht ins Gewicht. 

Die Maske sieht wie folgt aus, an den Stellen, an den die Bits 
gesetzt sind, d.h. der Punkt im einfarbigen Raster ist an dieser 
Stelle zu sehen, ist die Farbe des Sprites ’Hintergrundfarbe’. An 
der Stelle an der die Bits der Make gelöscht sind, sind auch die 
Punkte des Sprites ungleich der Hintergrundfarbe. Bei der Ver¬ 
knüpfung der Maske mit dem Bild (unser Hintergrund, auf dem 
sich der Sprite bewegt) wird dieses an diesen Stellen schwarz 
d.h. Farbe 0 (alle Bitplanes gelöscht, denn nur dann kann man 
erfolgreich das Sprite an diese Stelle kopieren). 

ö Kopieren des Sprites in den Bildschirm 

Es wird das Sprite, das sich als Bitmap (Bit Mapped - aufgeteilt 
in ein Bit "Tiefe" Speicherteile) im Speicher befindet - also im 
selben Format wie das des Bildschirmspeichers - auf die Stelle 
kopiert, an die wir zuvor die Löcher mit der Maske “eingestanzt" 
haben. Der Sprite wird dabei nicht einfach so hineinkopiert, weil 
ein Sprite eben auch ein viereckiges Stück ist (es würde viel zu 
lange dauern, den Sprite Punkt für Punkt (also Bit für Bit) an die 
richtige Stelle des Bildes zu kopieren). Um zu vermeiden, daß 
auch die nichtgesetzten Punkte mitkopiert werden, benutzt man 
die im Prozessor und Blitter fest "verdrahtete" Funktionen ’OR’ 
oder ’XOR’. Diese beiden Funktionen kopieren an die durch die 
Maske gelöschten Stellen die Bitplane des Sprites. Das alles 
geschieht natürlich immer dann, wenn der Bildschirm mit dem 
man das macht, gerade nicht vom Videoshifter angezeigt wird! 
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2.2 Die Realisierung! 

2.2.1 Voraussetzungen 

□ Bildsynchronisation 

Der Bildaufbau des Monitors wird zwar vom Computer gesteuert, 
erfolgt jedoch kontinuierlich (Zeile für Zeile). Der Programmierer 
hat dabei nur sehr geringe Möglichkeiten (50/60 Hz Umschaltung) 
Einfluß zu nehmen. Es muß jedoch sichergestellt sein, daß jedes 
Umschalten der Bildschirmseiten genau dann erfolgt, wenn das 
Monitorbild neu von oben aufgebaut wird. Wenn man die Umschal¬ 
tung der Bilder nicht mit dem Monitor synchronisiert, kann es pas¬ 
sieren, daß die eine Hälfte des Bildschirms schon das neue Bild 
darstellt, während auf andere Hälfte das alte Bild zu sehen ist. Um 
die Synchronisation zu ermöglichen, gibt es viele verschiedene 
Möglichkeiten. Ich möchte zuerst einmal eine relativ einfache Mög¬ 
lichkeit erklären, die, verglichen zu dem geringen Aufwand, den 
man bei der Realisierung betreiben muß, schon beachtliche Ergeb¬ 
nisse erzielt. Sie ist vor allem sehr leicht von Hochsprachen zu 
nutzen und erfordert keine Kenntnisse in Assembler (Programm, 
das vom Menschen verständliche 'Maschinensprache’ in Rechner 
verständliche umsetzt). Dazu muß man wissen, daß die Register 
(Videobasisregister - 3 Stück), in denen man die Adresse des dar¬ 
zustellenden Bildspeichers ändern kann, erst dann in den Shifter 
übernommen werden, wenn das nächste Monitorbild aufgebaut 
wird. Das kann unter Umständen bis zu 20 ms dauern. Man könnte 
natürlich, nachdem man das darzustellende Bild errechnet hat, den 
Bildschirmspeicher umschalten, abwarten bis der Shifter die neue 
Adresse übernommen hat und dann das nächste Bild vom Rechner 
aufbauen lassen. Das hat jedoch den Nachteil, daß man sehr viel 
Zeit damit vergeudet, darauf zu warten, daß der Videoprozessor 
die nächste Bildschirmseite anzeigt, damit man in die damit freige¬ 
wordene Seite vom Spieler unbemerkt das nächste Bild aufbauen 
kann. In Maschinensprache ließe sich der Bildaufbau noch so ge¬ 
schickt programmieren, daß er zeiltlich mit dem Anzeigen des 
nächsten Bildschirms zusammenfallen würde. In einer Hochspra- 
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che ist das effektiv nicht zu realisieren. Trotzdem muß man nicht 
unbedingt auf das Umschalten, das während der Dunkelphase des 
Monitors (Vertikal Blank abgekürzt ’VBL’) erfolgt warten. Einfacher 
ist es, wenn man 3 Bildschirmspeicher benutzt und dann, während 
der eine Speicher angezeigt wird, den zweiten mit den neuen Bild¬ 
daten beschreibt und der dritte darauf wartet, beim nächsten VBL 
angezeigt zu werden . 


Umschalten mit drei Bildschirmspeichem 


BiIdschirn - 

speieher 

1 

Bi Idschirn - ! 

Speicher 

2 

BiIdschirn - ; 

Speicher 

3 

fbearbeitet \Puffer 

Befehl zun uechseln bein nächsten Bildrü 

zuischendurch ! 

.2 

icklauf des 

angezeigt 

Ronitors 

BiIdschirn - 

Speicher 

1 

BiIdschirn - 

Speicher 

2 

BiIdschirn - 

Speicher 

3 

bein 

Puffer 

i nächsten fl 

i 

lufbau des 

i . i 

bearbeitet 

Bi Ides auf den Ronitc 

i . 

angezeigt 

jr 

Bi Idschirn - 

Speicher 

1 

BiIdschirn - 

Speicher 

2 

Bi Idschirn - 

Speicher 

3 

.; 

f. 

angezeigt 


bearbeitet 

\ Puffer 
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□ Das Umschalten der Bildschirmspeicher 
Da gibt es 3 Möglichkeiten (aller guten Dinge sind drei)! 

(1) Das direkte Beschreiben der Register des Videoschifters 
(dazu später mehr). 

(2) Das Beschreiben der Systemvariable die bei &44e d.h. an der 
Hexadezimalen (Zahlen zur Basis 16) auch $44e (Assembler) 
oder 0X044E (in C) geschrieben wird (dazu später mehr). 

(3) Den Betriebssystem-Aufruf 

Void Xbios(5,l:logadr%,l:physadr%,rezl) 

Einzelheiten, siehe Kapitel B.1.1.1 


□ Das Retten des Hintergrunds 

Da ich die ganze Sache in einer Hochsprache aufzeigen möchte, 
benutze ich natürlich einen Befehl, der dort vorhanden ist. Es ist 
der Befehl 

BMOVE PUFFER%,BILD%,MENGE% 

I I I 

I I I z.B. 32000 ST Standard Bildschirm 

I I 

I I z.B. Adresse eines Bildschirms beim 

I Page flipping 

I 

I_z.B. Hintergrund, auf den dann die Sprites kopiert werden 


'BMOVE funktioniert ähnlich wie ’memmove’ in der Programmier¬ 
spache ’C\ Es kopiert Speicherblöcke, man muß nur Anfangs¬ 
adresse, Zieladresse und Länge des Speicherblocks angeben, wo¬ 
bei sich der Quellblock und der Zielblock überlappen dürfen. 
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□ Das Kopieren der Sprites 

Dazu benutze ich wieder eine GFA-BASIC Funktion ’RC_COPY, 
die ähnlich funktioniert wie ’vro_copyfiri des VDI. 

RCjCOPY QUELL%, QUX&, QUY&,BRETT&,HOCH & TO ZIEL%,ZX&,ZY&, VERKN\ 

Quell% = Quelladresse 

QUX& = X - Quellposition } linke obere 
QUY& = Y - Quellposition } Ecke 

Breit& = Breite des Sprites (oder Maske) 

Hoch& = Höhe des Sprites (oder Maske) 

Ziel% = Adresse des Zielbildschirms (Seite beim ’page flipping’) 

ZX& = X - Zielposition} linke obere Zy& = y - Zeilposition} Ecke 

VERKNI = 4 für AND (MASKE), 7 für XOR (SPRITE) 

Maske und Sprite auf den Bildschirm kopieren 

1 2 3 


% 


1 


Orginal naske 





1 Hintergrund zurückschreiben 

2 Maske mit dem Hintergrund UND verknüpfen 

3 Orginal Raster mit dem Hintergrund ODER verknüpfen 
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2.3. Sprites ohne Maske 

Gelegentlich kann es sinnvoll sein, Sprites ohne eine Maske über 
den Bildschirm zu bewegen, z.B. an einer Stelle, an der der Bild¬ 
schirm leer ist oder nur eine Farbe hat oder monoton ist. In diesem 
Fall kann es sich lohnen, den Hintergrund in den Sprite einzubauen. 
Diese Technik wird z.B. an bestimmten Stellen bei dem Programm 
BODO (ich habe mal etwas mit dem Original! eines Freundes her¬ 
umexperimentiert) benutzt, es ist also durchaus gebräuchlich. Al¬ 
lerdings benutzt man am besten den Replace Modus ’1 ’ des 
RCjCOPY Befehls. Auch in meinem Beispielprogramm Sprites auf 
der Diskette werde ich diese Möglichkeit nutzen, wie auch die An¬ 
imation von Sprites mit einer Maske. 


2.4 Animation von Sprites 

Bei richtiger Animation bewegen sich nicht nur die Sprites, sondern 
sie verändern sich auch. Sie laufen, fliegen, springen, fahren u.v.m. 
Zeichentrickähnliche Grafiken sind in den heutigen Computerspie¬ 
len durchaus nicht unüblich, die Zeiten der starren Sprites mit fe¬ 
ster Form sind wohl endgültig vorbei!!! 

Die Realisierung benötigt fast keinerlei Rechnerzeit, man kopiert 
lediglich die Form des Sprites aus einem anderen Teil des Spei¬ 
chers, in dem man sich die Sprites holt. Dazu muß mann nur die X- 
und Y-Position der Quelle bei RC_COPY auf ein anderes Objekt 
richten. Bei der in meinem Beispielprogramm verwendeten Technik 
ist der Spritespeicher genau so wie der Bildschirmspeicher aufge¬ 
baut. Diesen habe ich vorher mit einem Malprogramm gezeichnet, 
so daß die Sprites sich leicht verändern lassen. Ich habe NEOC- 
ROME bzw. NEOCROME MASTER benutzt um die Sequenzen 
(eine Folge von Sprites) zu Zeichen. NEOCROME ist ein Public 
Domain Programm, also für jeden leicht zu erhalten. 

NEOCROME MASTER wird nicht kommerziell vertrieben, es wur¬ 
de von Demo-Programmierern um einige interessante Funktionen 
erweitert. Man kann damit z.B. Animationen direkt im Zeichenpro¬ 
gramm testen und es hat eine "tierisch“ schnelle Routine zum Dre¬ 
hen von Objekten u.v.m. . 
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A.3. Der Aufbau des Bildschirm¬ 
speichers 

oder wie erzeugt die Funktion *WHITE * aus 'Argon 4’ die Maske ? 

3.1 Die 3 Bildschirmauflösungen des Atari ST 

Hohe (ST) mit 640*400 Punkten Monochrom, d.h. nur eine Bit¬ 
plane und zwei Farben (Vordergrund und Hinter¬ 
grundfarbe) 

Mittlere (ST) mit 640*200 Punkten 4 Farben d.h. z.B. 2 Bitplanes 

Niedrige (ST) mit 320*200 Punkten 16 Farben d.h. vier Bitplanes, 
die meistbenutzte Auflösung für Spiele 

Der TT hat zudem noch drei weitere Auflösungen 

Hohe (TT) 1280*960 wie (ST HOCH) 

Mittlere (TT) 640*480 Punkte wie ST niedrig 

Niedrige (TT) mit 320*480 Punkten 256 Farben d.h. acht Bitplanes 
wohl die zukünftige Auflösung für Spiele auf dem TT 

Der Falcon 030 hat einige neue Auflösungen und unterstützt die 

TT-Auflösungen nicht komplett. 


Mögliche Auflösungen des Falcon 030: 


Normal 

1 Overscan 

1 Farben 

640*400 

1 768*480 

1 2/4/16/256 


1 

1 65535 (nur Interlace) 

320*400 

1 348*480 

1 4/16/256/65536 

320*200 

1 320*240 

1 4/16/256/65536 

640*200 

1 768*240 

1 2/4/16/256/65536 


zusätzlich sind alle ST Auflösungen möglich . 
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3.1.1 Die Hohe Auflösung (ST) 

ln der 640*400 Auflösung ist der ATARI ST sehr augenschonend. 
Mit einer Bildwiederholfreqenz von 71 Hz kommt er den von ver¬ 
schieden Organisationen geforderten 100Hz Monitoren viel näher 
als andere Computer in seiner Preisklasse. In dieser Auflösung 
kann der Atari ST (leider) nur noch zwei Farben (schwarz und 
weiß) darstellen. Der Bilschirmspeicher besteht aus nur einer Bit¬ 
plane, aber was bedeutet das ? Das bedeutet, daß die ersten 16 
Punkte des Bildschirms auch im ersten Wort (2 Byte bzw. 16 Bit) 
Platz finden. Ist ein Bit an, das bedeutet auf 1 gesetzt, dann hat 
dieser Punkt nicht mehr die Bildschirmfarbe (Hintergrund), son¬ 
dern, da es nur zwei Farben gibt, die Farbe von gesetzen Punkten. 
Natürlich stehen in Wirklichkeit keine Einsen und Nullen im Spei¬ 
cher, es sind nur geöffnete und geschlossene Schalter und wie je¬ 
des Gerät reagiert der Computer auf diese Schalter. In unserem 
Fall reagiert der Videoshifter auf offene Schalter mit der Hinter¬ 
grundfarbe und auf geschlossene mit einem gesetzten Punkt. 
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3.1.2 Die Mittlere Auflösung (ST) 

ln dieser Auflösung kann ein 'normaler’ Atari bis zu 640*200 Punk¬ 
ten mit 4 Farben darstellen, man schreibt im allgemeinen 640*200*2 
wobei man Zahl '2' am Schluß Bittiefe nennt, diese Art der Schreib¬ 
weise benutzt man z.B. bei speziellen Grafikmaschienen. Mit zwei 
Bitplanes kann man bis zu vier Farben (drei und die Hintergrund¬ 
farbe) darstellen. Der Grund dafür ist Relativ einfach, da man zwei 
Bitplanes nur auf vier unterschiedliche Arten zusammenstellen 
kann ! 


zweite Plane 

Farbe 0 (Hintergrund) 

1 

0 

1 

0 

erste Plane 

Farbe 1 

0 

1 


Farbe 2 

1 

0 


Farbe 3 

1 

1 



Nun sind die Planes nicht hintereinander in einem Byte oder einem 
Wort, sondern: 

1. Wort 1.Plane für 16 Pixel 

2. Wort 2.Plane für 16 Pixel 

Diese Auflösung wird nur für einige wenige Spiele genutzt, z.B. 
schalten einige Adventures (z.B. The Pawn) an der Stelle, an der 
die Grafik, die 16 oder mehr Farben enthält, endet, die Auflösung 
um, damit sie für den Text die 80 Zeichen pro Zeile, die in der mitt¬ 
leren Aulösung leicht möglich sind,nutzen können. 
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3.1.3 Die Niedrige Aulfösung (ST) 

Diese Auflösung wird wohl am meisten für irgendwelche Spiele ge¬ 
nutzt, da man relativ viele Farben (16) zur Verfügung hat, und mit 
einigen Tricks auch alle 512 bzw. 4096 Farben gleichzeitig darstel¬ 
len kann (dazu später mehr). Die Auflösung 320*200*4 übertrifft bei 
weitem das, was ich mir zu meinen 8 Bit Zeiten vorstellen konnte, 
ist jedoch heute zu Zeiten von VGA und Super VGA nichts Beson¬ 
deres mehr. Es gab jedoch 1985 (als der ST veröffentlicht wurde) 
weder VGA noch Super VGA Karten. Der Standart war Hercules- 
Monochrom- und CGA-Grafikkarten, die kaum mit den Auflösungen 
des ST mithalten können. Doch die Zeiten ändern sich und so die 
Standards. Die Speicheraufteilung der niedrigen ST-Auflösung ist 
im Prinzip die der mittleren, außer daß zwei Bitplanes mehr zur 
Verfügung stehen. 

Farben _ I Bitplanes 

Farbe 0 (Hintergrund) I 0000 

Farbe 1 I 0001 


I .... 

Farbe 15 11111 


Reihenfolge der Planes im Speicher! 

1 .Wort 1 .Plane für 16 Pixel 

2. Wort 2.Plane für 16 Pixel 

3. Wort 3.Plane für 16 Pixel 

4. Wort 4.Plane für 16 Pixel 
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3.1.4 Die Hohe Auflösung (TT) 

Diese ist vergleichbar mit der hohen ST-Auflösung, allerdings mit 
einer Auflösung von 1280*960 Punkten, die wiederum mit einer 
Bildwiederholfrequenz >70 Hz auf den entsprechenden Monitor ge¬ 
bracht werden. 


3.1.5 Die Mittlere Auflösung (TT) 

Ist vom Aufbau mit der niedrigen ST Auflösung vergleichbar, aller¬ 
dings mit 640*480 Punkten, was der Standard VGA-Auflösung ent¬ 
spricht. 

3.1.6 Die Niedrige Auflösung (TT) 

Eine meiner Lieblingsauflösungen auf dem TT, da bis zu 256 Far¬ 
ben (ohne Tricks) gleichzeitig möglich sind. Mit Tricks sind sogar 
(fast ohne jegliche Einschränkungen) 4096 Farben gleichzeitig 
möglich. Die 320*480*8 Auflösung übertrifft sogar die beim PC für 
Spiele übliche 320*200*8 (MCGA) Auflösung. Sie ist für mich die! 
Auflösung für Spiele auf dem TT und ich hoffe, daß sie bei den 
nächsten Umsetzungen von PC auf Atari nicht unberücksichtigt 
bleiben wird. 

Farben _ I Bitplanes 

Farbe 0 (Hintergrund) I 00000 

Farbe 1 I 00001 


Farbe 255 I 11111 

Reihenfolge der Planes im Speicher! 

1. Wort 1 .Plane für 16 Pixel 

2. Wort 2.Plane für 16 Pixel 


8.Wort 8.Plane für 16 Pixel 
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3.1.7 Die Auflösungen des Falcon 030 

Die Bitplanes sind beim Falcon, bis auf eine Ausnahme, genau so 
angeordnet wie bei den ST/STE/TT Auflösungen. Die Ausnahme ist 
die "True Color" Auflösung des Falcon ! 

In den "True Color'-Auflösungen wird keine Palette benötigt, da die 
Farbe aus den 16 Bit des Bildpunktes bestimmt wird. 

Ein Wort im Bildschirmspeicher: 

Bit 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 

RRRRRGGGGGXBBBBB 


R = rot 
G = grün 
B = blau 

X = niederwertiges (zählt am wenigsten) grünes Bit, das auch für 
Genlock verwendet wird. 

wenn X gelöscht Transparent (externes Video Signal) 
wenn X gesetzt Overlay (Falcon Video Signal) 

Zu dem True Color Modie kommen wir noch im Kapitel B.1 im 
zweiten Teil des Buches. 
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3.2. Wie erstelle ich daraus die Maske ? 

3.2.1 Sinn einer Maske 

Wie Sie im vorherigen Kapitel erfahren haben, ist es Sinn und 
Zweck einer Maske, ein Loch für die Sprites zu erzeugen, um mit 
den möglichen Arten der Verknüpfung, welche Hardwareeigen¬ 
schaften (Prozessor, Blitter) sind, das Bitmuster des Sprites so 
mit dem Hintergrund zu verknüpfen, das weder Hintergrund noch 
Sprites verfälscht werden. 


3.2.2 Voraussetzung 

Die Maske muß an der Stelle, an der irgendein Pixel gesetzt ist 
auch gesetzt sein, damit auch nur die Stellen des Zielbitfelds (Hin¬ 
tergrunds) gelöscht werden, an denen auch wirklich die Pixel des 
Sprites gesetzt sein sollen. Die Maske ist im Regelfall so beschaf¬ 
fen, daß nur die Pixel, die im Sprite gesetzt sind, auch in der Mas¬ 
ke gesetzt sind. 


3.2.3 Erzeugung 

Um die Maske zu erzeugen, nimmt man die ’OR’ Funktion des Pro¬ 
zessors oder des Blitters und "verodert" alle Bitplanes. Bei der 
’OR' Funktion werden alle Bits gesetzt, die im Quell -Zielbitfeld ge¬ 
setzt sind. Das bedeutet, wenn auch nur irgendein Bit gesetzt ist, 
also irgendein Punkt irgendeine Farbe hat, daß das entsprechende 
Bit auch in der Maske gesetzt wird. 
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3.2.4 Die Verwendung 

Ich könnte jetzt die Maske entsprechend der Menge Bitplanes, die 
ich habe, mehrmals mit dem Bildschirm verknüpfen. Diese Technik 
würde sich mit Betriebssystemroutinen nur schwer mit der nötigen 
Performance realisieren lassen. Um dieses Problem zu lösen, 
schreibe ich die Maske schon von zu Beginn in alle Bitplanes, was 
zwar viermal so viel Speicher benötigt, aber wesentlich einfacher 
zu handhaben ist. Bei eigenen Spriteroutinen mit eigenen Bitblock¬ 
kopierroutinen sollte man jedoch diese Möglichkeit Speicher zu 
Sparen nutzen, ergo die Maske einzeln in alle Bitplanes kopieren !!! 
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A.4. Ein komplettes Spiel 

Ich gebe zu, daß das Spiel nicht mehr ganz dem 16 Bit Standard 
entspricht und ich mir keine besonderen Gedanken über den Spiel¬ 
witz gemacht habe, es ist ja auch keineswegs meine Absicht ge¬ 
wesen, ein aufregendes interessantes Spiel zu programmieren. 

Mir war es eigentlich wichtig ein Spiel zu programmieren, das mög¬ 
lichst anschaulich einige Verfahrensweisen im Bezug auf Spiele¬ 
programmierung aufzeigt. Das Spiel ist auf allen Rechnern schnell 
"genug", obwohl es zu 98% in GFA-BASIC geschrieben ist, die 
Maschienenroutinen wurde nur zum Erzeugen der Maske, des digi¬ 
talen Sounds und natürlich zur Umschaltung der Farben zwischen 
Score und Spielfeld, verwendet. Nun, es ist eben nur ein Beispiel, 
natürlich ließe sich mit etwas mehr Maschinensprache und einem 
guten Konzept ein Ballerspiel programmieren, das etwas länger 
Spaß macht. Aber mir war es wichtig, so wenig Assemblerroutinen 
wie möglich zu benutzen, um zu zeigen, daß man nicht unbedingt 
auf die kompliziertere Assembler-Ebene heruntersteigen muß, um 
brauchbare Animation und relativ flüssiges Scrolling zu realisieren, 
denn mit ein paar guten Ideen, etwas Kreativität und Grundwissen 
über den Aufbau der Hardware kann man manchmal mehr errei¬ 
chen als mit dem optimiertesten Stück Assemblercode. Es gibt 
auch noch Probleme beim Starten von 'Argon 4’ mit 'MULTI TOS’, 
da ich zum einen nur eine Beta Test Version von 'MULTI TOS’ zur 
Verfügung hatte (trotzdem vielen Dank an Atari Deutschland) und 
zum anderen ein schnelles Action-Spiel in einer Hochsprache allein 
schon eine Herausorderung ist, wenn man sich dann noch an die 
Konventionen eines Multi-Tasking Systems halten muß (von dem 
man noch nicht genau weiß, wie es später, wenn es nun mal end¬ 
lich richtig fertig ist, mal aussehen wird) es also im Prinzip unmög¬ 
lich ist. Trotzdem habe ich schon einige Vorkehrungen getroffen, 
die eine höchst mögliche Kompatibilität versprechen, aber dazu 
später mehr. 
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4.1 Wie fange ich an ? 

Am Anfang ist die Idee, die schreibt man sich am besten gleich auf. 
Wenn mehr als nur eine Person an einem Programm arbeitet, un¬ 
terteilt man das Programm in mehrere sinnvolle Abschnitte, z.B. 
einer programmiert die Routine, die die Aliens bewegen, der ande¬ 
rer die Figur des Spielers und das Scrolling der Landschaft. Gut ist 
auch eine Unterteilung nach Können, denn nicht jeder kann alles 
gleich gut programmieren. Ein Beispiel hierfür ist, bei 'Argon 4’ die 
PSG Soundroutine hat Kay Römer geschrieben, denn er hat Erfah¬ 
rung mit Soundchip und Soundroutinen und programmiert gut opti¬ 
mierten Assemblercode! Also habe ich ihn so lange "angebettelt“, 
bis er sich dazu bereit erklärt hat, für mich die Routine für den 
"YAMA" Soundchip zu schreiben. Auf diesem Wege "Danke Kay !". 

Aber nicht nur Programmierer werden beim Spieldesign benötigt, 
auch Zeichner und Musiker. Da ich selbst schon lange Zeit Musik 
mache und gelegentlich auch zeichne, habe ich das bei 'Argon 4’ 
selbst übernommen (verzeiht mir). 

Ok, nehmen wir an, die Idee, die Musik, die Sounds und die Grafik 
sind ausgearbeitet. Ihr wißt daß alles realisierbar ist. Dann würde 
ein “Vollblut Informatiker" die benötigten Module (Procedueren) auf 
dem Reißbrett entwerfen. Das bedeutet, man schreibt sich erst 
einmal auf, welche Module man alle braucht. 

Beispiel: 

Joystick_Abfrage 
Fragt den Joystick Port A ab 
Wenn oben, wird X erhöbt 
Wenn unten, wird X erniedrigt 
u.s.w 


Spielersprite 

Bewegt je nach Wert von X und Y 

An den Rändern wird das Sprite geklippt(abgeschnitten) 

Gegersprite 

Bewegt sich von rechts oben nach links unten 
Verschwindet, indem es sich auflöst. 
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Wichtig ist, gerade bei mehreren Bearbeitern eines Programms, die 
Übergabeparameter, d.h. die Daten, die das eine Unterprogramm 
dem anderen übergibt, in ihrer Form (z.B. Byte, Wort, Integer, 
String, Bool), festzulegen. 

Zusätzlich beschreibt man die Funktion der Module in einer Pseudo 
Computerspache, einer sogenannten PDL. Bei der PDL (Programm 
Design Language) wird die Funktion des Moduls erklärt, wobei 
auch Strukturelemente und Schleifen benutzt werden, aber die 
restlichen Befehle umgangssprachlich hingeschrieben werden. 

Beispiel: 

Modul: Spritejbewegen 
IF Sprite außerhalb der Ränder 

klippe Sprite (abschneiden an den Rändern, so daß es nicht weitergezeichnet 
wird). 

zeichne geklipptes Sprite 

ELSE 

zeichne ganzes Sprite 

END 

Wenn man alle Module so definiert hat, erstellt man eine Modulhie- 
rachie, d.h. man "malt" Kästchen, die miteinander mit Pfeilen ver¬ 
bunden werden, die aufzeigen, wer wen aufruft und welche Module 
untergeordnet sind. 

"Richtig“ gute Informatiker (solche Leute, die Computer und ihre 
Programmierung studiert haben) betreiben sogar noch ein bißchen 
mehr Aufwand, aber belassen wir es hierbei. 
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Nun, wer dann soweit ist, ist einem fertigen Spiel schon sehr nahe, 
aber wer als Anfänger kommt schon soweit, das artet ja in Arbeit 
aus. Das erste Spiel sollte leicht zu programmieren sein und man 
sollte in jeder Stufe der Schöpfung einen Fortschritt sehen können. 
Das läßt sich nur dann realisieren, wenn man das Programm wie 
eine Zwiebel aufbaut, Schale für Schale. Zum Beispiel könnte man 
bei einem Ballerspiel, zuerst den Fighter zeichnen und ihn dann 
über den Bildschirm bewegen. Dann den Hintergrund entwerfen 
und dann den Fighter über den Hintergrund bewegen, den man sei¬ 
nerseits sich wieder bewegen lassen könnte. Dieses Prinzip hat ei¬ 
nen höllischen Nachteil, wenn man das Programm schlecht doku¬ 
mentiert (also nicht immer dahinter schreibt, was man macht, sollte 
man immer machen) steigt man irgendwann nicht mehr durch (!) 
und man muß alle Module so offen programmieren, daß man im 
Notfall noch etwas dazu packen kann, man weiß ja nie was an die¬ 
ser oder jener Stelle noch dazugefügt werden muß. Aber, wie 
schon erwähnt, hat man bei dieser Art zu programmieren immer 
wieder ein Erfolgserlebnis, was ganz schön aufputschen kann. Bei 
kleineren Programmen ist die "Zwiebelschalen" Methode die moti- 
vierendere Art zu programmieren ! 'Argon 4’ liegt an der obere 
Grenze eines Programmes, das mit dieser Art zu programmieren 
realisierbar ist. Bei größeren Projekten verzettelt man sich sonst 
allzusehr. Gerade wenn mehrere Personen an einem Projekt pro¬ 
grammieren, sollte ein Konzept und die Schnittstelle zwischen den 
Programmteilen feststehen, z.B. 

ein Programmteil spielt die Musik, dann könnte man festlegen, 

a) Wie übergeben wird welches Musik Stück gespielt wird ? 

z.B. als Zeiger (eine Variable die als Inhalt die Startadresse ei¬ 
nes bestimmten Speicherbereichs enthält) auf die Noten enthält 

oder es wird ein String mit Noten u.v.m. übergeben. 

b) In welchem Format die Noten vorliegen ? 

z.B. im XBIOS(32) also in einem Betriebssystem eigenen For¬ 
mat. 
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c) Wieviel Rechenzeit steht dem Rest des Programms noch zur 
Verfügung während die Musik spielt ? 

z.B. nur noch 10% bei mehrstimmigem, digitalem Sound (dann 
geht sonst fast nichts mehr) oder noch 95% bei Soundchip Mu¬ 
sik. 

d) Wieviel Speicher darf die Abspielroutine in Beschlag nehmen ? 

z.B. eine Routine, die dann den Rest des Programms nachlädt, 
darf fast den gesamten freien Speicher (sofern nötig) für sich in 
Anspruch nehmen und ihn nach dem Abspielen eines solch lan¬ 
gen Samples frei geben und der Haupt-Applikation zur Verfü¬ 
gung zu stellen. 

Allerdings, wenn die Abspielroutine nur ein Teil des Program¬ 
mes ist und vielleicht noch wärend des Spiels läuft, muß sie 
dem Rest des Programms genügend Speicher übrig lassen bzw. 
muß sichergestellt sein, daß für den Sound noch genügend 
Speicher frei ist. 

Auch sollte man sich mit dem "Grafiker" einig sein wieviel Far¬ 
ben er nutzen darf und welche, nicht das ein Programm mit 16 
Farben laufen soll und der Typ malt mit 256 oder er malt tat¬ 
sächlich mit 16 Farben, hat aber kein einziges Farbregister für 
irgenwelche Hintergünde übriggelassen. Worüber man sich vor¬ 
her einig ist kann es später keinen Streit geben (!) am besten 
alles aufschreiben und jedem ein Exemplar der Übereinkünfte 
ausdrucken lassen. 
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4.2. Das Programmieren des Spiels 

Man sollte die Programmteile, wie schon oben erwähnt, so offen 
wie möglich gestalten, da man sie dann auch in anderen Program¬ 
men benutzen kann. Beispielsweise läßt sich die Soundroutine von 
'Argon 4’ auch in einem von Deinen Programmen verwenden. Wenn 
man Programme in Programmteile zerlegt, sammelt sich mit der 
Zeit eine ganze Bibliothek von Modulen an, die selbst wenn das 
Projekt, für die das eine oder andere Modul geschrieben wurde, ein 
Fehlschlag war, bei der Realisierung des nächsten Spiels von Vor¬ 
teil sein kann. 

4.2.1. Die Animation in Argon 4 

Stelle aus Argon 4 in Procedure 'MAIN* 

’ ********** setzt neue Bildschirmadresse (pageflipping) 

VOID XBIOS(5,L:scmem%(flipl),L:scmem%(flipil),-1) 

BMOVE scrollup%+s_off%,scmem%(flipl),28960 


Genau diese Stelle ist das Herz der Animation ! 

ln der indizierten Variable ’scmem%()’ sind die Zeiger auf die drei 
Bildschirmspeicher, die ich zum Pageflipping (siehe auch die letz¬ 
ten beiden Kapitel) benutze, gespeichert. Das Umschalten ge¬ 
schieht an anderer Stelle in der Procedure 'MAIN' und zwar vor der 
eigentlichen Umschaltung (Listing oben). Der Videoshifter setzt die 
neue Adresse erst kurz vor dem Bildaufbau des nächsten Monitor¬ 
bildes, also volkommen synchron. Der Aufruf ’XBIOS(5)’ be¬ 
schreibt den Videochip mit der als nächstes zu setzenden Adresse 
und versorgt das Betriebssystem mit der neuen Adresse des (mit 
VDI, Line A etc.) logischen Bildschirmspeicher, auf den es schrei¬ 
ben soll. Da diese beiden Adressen nicht übereinstimmen, sieht 
man erst bei jeder dritten (!) Umschaltung den zuletzt beschriebe¬ 
nen Bildschirmspeicher. 
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Aus Procedure 'MAIN' 


INC flipl ! Zähler für das "Page Flipping" 

IF flipl=4 
flipl=1 
ENDIF 

(Weit) Hinter der Umschaltung findet das Setzen von ’flipil’ statt. 
Von Procedure 'MAIN' 


flipil=flipl 

Durch diese Technik ist Flackern (fast) ausgeschlossen. 
Aus Procedure 'MAIN 


RC_COPY maske%,1+offset&,1+kapl,21,longl TO scmem%(flipl),x&,y&,1 
RC_COPY sprite%,1+offset&,1+kapl,21,longl TO scmem%(flipl),x&,y&,7 

Wie man sieht, findet die Variable ’flipP auch bei den Raster-Ko- 
pierbefehlen Anwendung, in dem oben gezeigten Listing wird der 
"Fighter" von dem Bild, das sich an Adresse ’sprite%’ befindet auf 
den gerade aktuellen nicht angezeigten (!) logischen Bildschirm¬ 
speicher kopiert. Zuvor wird allerdings seine Maske auf dem Bild¬ 
schirmspeicher kopiert, um die Stelle, an der das Sprite hin soll, 
frei von Bildpunkten des Hintergrunds zu bekommen, da es sonst 
bei den Verknüpfungen der Bitplanes zu anderen Farben kommt als 
die, die man beim Zeichnen verwendet hat. Die Variable ’kapl’ gibt 
an welche Phase des Fighters zu sehen ist (fliegt er nach links 
oder rechts), ’offset&’ gibt an, ob ein heiler oder ein kaputter Fight¬ 
er gezeichnet werden soll und ’longl’ ob er mit oder ohne Düsen¬ 
flackern gezeichnet werden soll. 


45 



Spiele selbst programmieren 


Mit BMOVE scrollup%+s_off%,scmem%(flipl),28960 

in der Procedure 'MAIN' wird der zu scrollende Hintergrund in den 
logischen Bildspeicher kopiert. Das geschieht natürlich bevor die 
Sprites hingezeichnet werden. Sonst würden diese ja sofort über¬ 
schrieben werden. Im Prinzip funkioniert das wie beim Malen mit Öl 
- Farben, das zuletzt Gezeichnete ist immer das Oberste, nur an¬ 
trocknen lassen muß man die Farbe nicht. 


4.2.2 Das Scrollen des Hintergrundes 

Das Scrollen des Hintergrundes ist beim vertikalen Scrolling eine 
relativ einfache Sache! Da ich sowieso dauernd den Hintergrund 
neu zeichnen muß, da das in Basic schneller geht als alle von den 
Sprites überdeckten Stellen neu zu zeichenen, kann ich natürlich 
auch jedesmal einen anderen bzw. verschobenen Hintergrund 
übertragen. Nun habe ich mir, bevor ich die Procedure ’MAIN’ star¬ 
te, eine größere Menge Speicher für das Scrolling reserviert und 
dann aus geladenen Bildern diesen Speicher mit entsprechenden 
viereckigen Stücken (wie bei einem Puzzle) gefüllt. Da ich die 
Grundlage für die Bilder zum Erstellen des Scrollspeichers so frei 
wie möglich definiert habe, kann ich mit einem 32k großen Bild eini¬ 
ge 100k Scrollspeicher füllen. Ich verschiebe also die Adresse, von 
der ich den Hintergrund in einen als Bildspeicher vorgesehenen Be¬ 
reich, immer um 160 Bytes (nur im 1.Level, im 2. Level 320 Bytes 
usw.), was einer Zeile in niedriger Auflösung entspricht. Obwohl 
das im Prinzip Feinscrolling ist, ruckelt die Sache ein klein wenig. 
Das kommt durch den unterschiedlichen Rechenaufwand des 
Rechners je nach Spielverlauf. Wenn zum Beispiel viele Aliens auf 
dem Bildschirm erscheienen, dauert es länger, bis der Rechner 
auch den nächsten der drei Bildschirme schalten kann und somit 
dauert es auch länger, bis ich die nächsten 160 Bytes dazuaddieren 
kann... und wieder umschalten kann. Programme, die vollkommen 
in Assembler geschrieben wurden, können das Scrolling mit dem 
VBL synchronisieren, z.B. könnte man den Offset zum Beginn des 
Scrollspeichers alle zwei VBL’s um 160 Bytes erhöhen und schon 
hätte man relativ gleichmäßiges Scrolling. 
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4.2.3 Animation der Objekte 

4.2.3.1 Die Bewegungen der Aliens 

In Procedure alienl und alien2 

Zeichnen der Aliens in Procedure q_alienl und q_alien2 

Das Bewegen der Aliens funktioniert prinzipiell genauso wie das 
Bewegen des Balls von unserem ersten Spiel im Kapitel 1. Nur das 
in 'STAGE T die Aliens, wenn am unteren Rand angekommen, 
nicht nach oben abprallen sondern aus dem unteren Rand heraus¬ 
fliegen, um am oberen Rand wieder aufzutauchen. Wenn ein Alien 
von 'STAGE T aus dem unteren Rand verläßt, muß es geklippt 
werden, d.h. Teile, die über den Rand des Spielfelds überstehen, 
dürfen nicht gezeichnet werden, da sie sonst an der Stelle erschei¬ 
nen, wo die Punktzahl (Score) angezeigt wird. Da an dieser Stelle 
der Hintergrund nicht andauernd redrawed (neu gezeichnet) wird, 
würde ein Alien an dieser Stelle die hübsche Anzeige (mit satten 14 
neuen Farben) am unteren Bildrand teilweise mit einem Alien über¬ 
deckt werden; das sieht dann nicht gerade professionell aus. 

Die Aliens von 'STAGE 2’ bewegen sich genauso wie der Ball vom 
Spiel von Kapitel 1. Bei jedem abgeschossenen Alien wird ein Boo- 
lean (Bitvariable) auf False gesetzt. Per Zufallsgenerator wird "ent¬ 
schieden" ob wieder ein neues Alien erscheinen soll. Bei jedem 
neuen Erscheinen eines Aliens wird eine Variable hochgezählt, 
denn nach einer im Programm festgelegten Anzahl von Aliens er¬ 
reicht man den nächsten STAGE. 

Wichtige Variablen: 

- Index 

all 

Die Bytevariable 'all' gibt den Index für die meisten der in Aliens 
benutzten Variablen. Da alle Aliens einer Stage denselben Algorith¬ 
mus zur Bewegung benutzen, wäre es wenig sinvoll gewesen für 
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jeden Alien die Bewegungsroutine erneut aufzuschreiben. So habe 
ich die wichtigsten Variablen der Bewegung indiziert und lasse 
mehrmals den gleichen Programmteil durchlaufen, es wird bei je¬ 
dem Durchlauf der Schleife mit der boolschen Variablen ’init!(al\)’ 
getestet ob das Alien existiert, also ob es nicht schon abgeschos¬ 
sen oder noch gar nicht erschienen ist, und gegebenenfalls ge¬ 
zeichnet. 

- Animation des Alien 

ani&(all) 

- Position des Alien 

X Position alx&(all) 

Y Position aly&(all) 

- existiert das Alien ? 

imt'(all) 


4.2.3.2 Die Bewegung des Mutterschiffs 

In Procedure mother 

X Position mx& 

Y Position my& 

Das Mutterschiff bewegt sich immer zum Fighter hin, wobei das 
Mutterschiff sich ständig nach links und rechts bewegt. Wenn der 
Fighter sich horizontal bewegt, folgt ihm das Mutterschiff. Das 
Mutterschiff folgt langsam dem Fighter, je nachdem ob er sich 
oberhalb oder unterhalb des Mutterschiffs befindet und versucht, 
ihn zu zerquetschen. 
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4.2.4 Kollision der Objekte 

4.2.4.1 Kollision von Schuß mit Alien oder Mutterschiff 

Diese Kollision wird in den Proceduren mother,alienl,alien2 getestet. 
Die Kollision wird durch Vergleichen von Rechtecken, die den Aus¬ 
maßen der Objekte entsprechen, getestet. Überschneiden sich die 
Rechtecke zweier Körper, kommt es z.B. zu einer Explosion. Da 
ein Schuß eine Breite von Null hat, brauche ich in diesem Fall nur 
die Berührung einer Geraden mit einer Fläche zu prüfen, was min¬ 
destens ein Vergleich weniger im ’IF THEtf zur Folge hat. Es wer¬ 
den jeweils alle drei Schüsse auf Berührung mit einem Alien bzw. 
dem Mutterschiff getestet, daher die 'FOR - NEXT Schleife. 


Kollision von Alien mit Schuß: 

colx&, coly&, caly& werden zuvor berechnet um beim ’IF THEN’ 
Zeit zu sparen. 


colx&=alx&(all)+10 

coly&=aly&(all)+10 

caly&=aly&(all)-10 


' ***** Kollision mit Schuß 
FOR nl=1 TO 3 
IF shoot!(nl)=TRUE 

IF shx&(nl)=>alx&(all) AND shx&(nl)<=colx& AND shy&(nl)>=caly& AND shy&(nl)<=coly& 
shoot!(nl)=FALSE 
alcol 
ENDIF 
ENDIF 
NEXT nl 
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Mutterschiff mit Schuß: 

colx&, coly&, wedelx& werden zuvor berechnet um beim ’IF THEN’ Zeit zu sparen. 


coly&=my&+38 
colx&=mx&+wedell+130 
wedelx&=mx&+wedell 


FOR nl=1 TO 3 
IF shoot!(nl)=TRUE 
’ treffer ? 

IF shy&(nl)<coly& AND shx&(nl)<colx& AND shx&(nl)>wedelx& AND y&>coly& 
IF shx&(nl)>wedelx&+49 AND shx&(nl)<wedelx&+60 
' An der schwachen Stelle ? 

’ ******* Treffer in Mother Sound 

saml=4 

rplay_sound 

» ****************************** 

SLPOKE &H44E,gegner% ! ändere logischen Bilschirmspeicher 
sberx&=shx&(nl)+263-wedelx&-50 

WHILE POINT(sberx&,140-ymothl)=0 AND mothexpl!=FALSE ! Farbig ? 

’ wenn nicht farbig 

IF ymothl>13 ! Sehr tief ins Mutterschiff eingedrungen ? 
mothexpl!=TRUE 
motl=132 
animatl=1 

’ ******* Mother, Explosionsgeräusch 
saml=1 

rplay_sound 
• *************** 

ymothl=0 
ELSE 
INC ymothl 
ENDIF 
WEND 

, ********* striche in schwacher Stelle 
COLOR 0 

LINE sberx&, 140-ymothl,sberx&, 138-ymothl 
COLOR 1 

SLPOKE &H44E,maske2% 

LINE sberx&, 140-ymothI,sberx&, 138-ymothI 
shoot!(nl)=FALSE 
y moth 1=0 
ELSE 

shoot!(nl)=FALSE 
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»****** Sound, Mother nicht getroffen 
saml=2 

rplay_sound 
• ************ 

ENDIF 

ENDIF 

ENDIF 

NEXTnl 


4.2.4.2 Kollision des Fighters mit Alien und Mutterschiff 

Diese Kollision wird in den Proceduren mother.alienl ,alien2 gete¬ 
stet. 

Kollision mit Mutterschiff: 

Auch hier wird zuvor (siehe 4.2.4.1) colx&, coly& berechnet! 

IF x&+11>mx& AND x&+11<colx& AND y&+19>my& AND y&<coly& 
colission 

ENDIF 

Kollision mit Alien: 

IF x&+11>alx&(all) AND x&+11<colx& AND y&+19>aly&(all) AND y&<coly& 
colission 
alcol 

ENDIF 


4.2.4.3 Kollision des Fighters mit dem Hintergrund 

Diese Kollision wird in der Prozedure main getestet 

Im Gegensatz zu der zuvor benutzten Methode, wobei ich die Kolli¬ 
sion durch Vergleich der Ausmaße der Körper getestet habe, teste 
ich hier auf eine bestimmtes Farbregister. Falls also der Fighter an 
einem der drei Punkte des Fighters die ich auf Berührung mit einer 
Farbe prüfe, das Farbregister Nummer neun berührt, wird die Pro- 
cedure Kollision aufgerufen, die erst dann eine Kollision zuläßt, 


51 



Spiele selbst programmieren 


wenn die Animation beendet ist, die anzeigt, daß der Fighter getrof¬ 
fen wurde, indem er die Boolche Variable ’hit!’ auf ’true’, was 'wahr’ 
bedeutet, setzt. Eine Kollision zu prüfen wäre in diesem Fall auf ei¬ 
ne andere Art auch schlecht möglich, da das Programm ja nie ge¬ 
nau weiß, wo sich die gefährlichen Objekte im Hintergrund befin¬ 
den. 

IF POINT(x&+10,y&)=9 OR POINT(x&+20+small&,y&+15)=9 => 

=> OR POINT(x&,y&+15-small&)=9 AND hit!=FALSE 
colission 
ENDIF 

In der Procedure ’colission wird dann ein Flag gesetzt, also eine 
Boolsche Variable, die angibt, ob ein Ereignis eingetreten ist und 
mit dem PSG ein "brummiger Rüttelsound" gespielt. 
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4.3 Joystick und Keyboard 

4.3.1 Die Abfrage des Joysticks 

Es wird immer nur der Joystick Port Nr.1 abgefragt. 

JOYSTICK POSITION: 


5 1 9 
\ I / 

4- 0-8 
/1 \ 

6 2 10 

Was man bei der hier gezeigten schematischen Darstellung der 
ausgegebenen Werte beim Drücken in eine bestimmte Richtung be¬ 
achten muß, ist das System bei der Anordnung der Zahlen. So ist 
links=>4 + oben=>1 links&oben=>5 , so daß man beim genauen 
Hinschauen bemerkt, daß die Seiten links, rechts, oben, unten je¬ 
weils einem Bit zugeordnet sind, 

Bit 0, oben 
Bit 1, unten 
Bit 2, links 
Bit 3, rechts 

und die schrägen Joystickpositionen jeweils eine ’OR’ Verknüpfung 
der Richtungsbits der geraden bedeutet. Wenn man mal einen Joy¬ 
stick öffnet und z.B. die Betätiger (z.B. Mikroschalter) von oben 
und unten gleichzeitig betätigt erhält man eine 3, was wiederum be¬ 
deutet, daß effektiv 16 (4 Bit) Joystick Positionen statt 9 möglich 
wären, wenn man einen entsprechenden Joystick bauen würde. 
Man könnte allerdings die zusätzlichen Verknüpfungen der Tasten 
auch mit Funktionen wie Pause oder ähnl. belegen. 
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In Procedure 'mairi 

SELECT STICK(I) 

CASEO 
in_mitte 
CASE 1 
oben 
in_mitte 
CASE 2 
unten 
in_mitte 
CASE 4 
links 
CASE 8 
rechts 
CASE 5 
links 
oben 
CASE 9 
rechts 
oben 
CASE 6 
links 
unten 
CASE 10 
rechts 
unten 

ENDSELECT 

ln den Proceduren 'links’, 'rechts 1 , 'oben', 'unten', werden die 
entsprechenden Variablen zur Steuerung des Fighters verändert. 


4.3.2 Tastenabfrage 

Ich hatte eigentlich geplant, die Abfrage der Tasten über das BIOS 
"laufen zu lassen" , mit der GFA - Basic Funktion ’INP(2)’, die 
BIOS(2), also ’Bconin’, benutzt. Beim Testen mit MULTI -TOS 
mußte ich feststellen, daß ich diese Funktion nicht so schnell ab- 
fragen kann, daß das AES die eingegebene Taste nicht erhält. Da 
aber das AES weiterhin im Hintergrund läuft und gelegentlich ein 
Tastendruck zur Ereignisverwaltung durchkommt, weil ich den Puf¬ 
fer nicht schnell genug leeren kann, bekomme ich natürlich diese 
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Taste nicht gemeldet, da das AES mit dem Auslesen der Taste die¬ 
se aus dem Tastaturpuffer löscht, was in diesem Fall bedeuten 
würde, daß die Tastaturabfrage unter MULTI - TOS mal funktioniert 
und mal nicht funktioniert. Daher habe ich entschieden, die kom¬ 
plette Tastaturabfrage über das AES abzuwickeln, was zwar durch 
die langen Funktionsaufrufe etwas mehr Rechenzeit in Anspruch 
nimmt, als wenn man das mit dem BIOS regelt, aber auf jeden Fall 
auch unter MULTI - TOS funktioniert. 

Wobei die Abfrage der Tasten etwa so erfolgen muß ! 

zuerst 

ON MENU KEY GOSUBxyz 

wobei dieses Richten der AES Funktion auf eine Unterroutine, in 
diesem Fall ’xyz’, vor dem Eintritt in eine Schleife zu erfolgen hat, 
die dann 

REPEAT 
ON MENU 
UNTIL... 

das ON MENU sorgt für das ständige Abfragen, ob ein AES Event 
aufgetreten ist. Wenn dieser EVENT aufgetreten ist, verzweigt das 
Programm bei dem ON MENU zu ’xyz’ 

dort kann man in MENU(14) in den Bits 0..7 den ASCII Code finden 
und in den Bits 8 .. 15 den Scancode. 


4.4 Verwaltung von Highscore Liste 

Das Verwalten einer High Score Liste ist im Prinzip eine recht ein¬ 
fache Sache. Man hat also eine Liste von geordneten (!) Werten 
und einen Wert, den man in die Liste einordnen will. Man testet je¬ 
den Wert, der in der Liste steht, mit dem Wert, den man einordnen 
möchte. Wenn man einen kleineren Wert in der Liste findet als den 
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den man einordnen möchte, wird der Rest der Liste um eine Stelle 
in der Liste nach unten geschoben und der Wert, mit dem man ver¬ 
glichen hat, an die Stelle des kleineren Werts geschrieben. Natür¬ 
lich dürfen bei High Score Listen die Namen nicht fehlen, diese 
müssen natürlich dann genau so wie die entsprechenden Scores in 
der Liste verschoben werden. 

> PROCEDURE high_score ITestetob Score in High Score 
WAVE 0,0 
ch_palette 
p_cls 

’ ****** welcher Platz ? ********* 

FOR tl=1 TO 10 

EXIT IF high%(tl)<score%(mitspl) 

NEXT tl 

, ****** | nner h a |b ? ********** 

IFtkll 

’ ******* Rest um einen Plaz nach unten ***** 

FOR nl=10 DOWNTO tl 
high%(nl+1 )=high%(nl) 
high$(nl+1)=high$(nl) 

NEXT nl 

> ******************************* 

high%(tl)=score%(mitspl) Iscore in Liste eintragen 

high$(tl)=SPACE$(20)!neuen Eintrag löschen 

h_o_fame 

taste!=FALSE 

posl=0 

DEFTEXT tl+3 

ON MENU KEY GOSUB high.name 
REPEAT 

. ******** Bünden d es “Cursors“ ******** 

IF blink!=TRUE 
blink!=FALSE 
TEXT 50+posl*8,50+tl*8/ “ 

ELSE 

blink!=TRUE 

TEXT 50,50+tl*8,high$(tl)+" “ 

ENDIF 

» *************************************** 

ON MENU 
UNTIL taste!=TRUE 
ELSE 
h_o_fame 
w_key 
ENDIF 
RETURN 
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4.5 Das Abspielen der Musik 

Nähere Einführung zu den hier beschriebenen Effekte im Kapitel 
B.4 zu Sounderzeugung! 

Wie man unschwer bemerkt, spielt das Spiel, nach dem alle Pro¬ 
grammteile eingeladen wurden, eine hübsche kleine Musik. Wie 
man bei mir leicht vermutet, habe ich dazu eine eigene Abspielrou¬ 
tine in BASIC geschrieben, die es aber in ihrer Leistungsfähigkeit 
mit vielen Maschinenroutinen aufnehmen kann. Diese ist so ge¬ 
schrieben, daß man sie gegebenenfalls ohne größere Probleme 
auch in Maschinensprache umsetzen könnte. Natürlich hat das 
Schreiben einer solchen Abspielroutine in BASIC einen Haken und 
der ist zum einen die massig verschlungene Rechenzeit und zum 
anderen, daß die Routine schon fast in Höchstgeschwindigkeit 
läuft, noch schnelleres Abspielen würde die Qualität der Effekte wie 
Vibrato etc. unerträglich (zumindest für mein zartes Gehör) ma¬ 
chen. Wem die Musik, die meine kleine Routine abspielt, nicht ge¬ 
fällt, kann via ’COMPOSE.LST’ in dem File ’KAPA4.TOS’, eine ei¬ 
gene Musik komponieren. Dieser kleiner Composer ist natürlich 
kein anwenderfreundliches, mausgesteuertes Programm (noch 
nicht), sondern ein kleines Tool, mit dem man durch Eingabe von 
Datazeilen Musik komponieren kann, die dann z.B. von der Ab¬ 
spielroutine in ARGON 4, die fast identisch mit der in 
’COMPOSE.LST’ ist, abgespielt werden kann. 
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4.5.1 Die Funktionen der Abspielroutine 

Die Abspielroutine ist dazu fähig, dreistimmigen PSG Sound abzu¬ 
spielen und unterstützt auch das Rauschen in unterschiedlicher 
Tonhöhe. 

Frequenz: (16 Bit Wert) 

Stimmung, mittleres C = 440Hz 


1 . 

Oktave 2. Oktave 

3. Okt. 

4. Okt. 

5. Okt. 

6. Okt. 

c 

3395 

1697 

849 

424 

212 

106(105) 

c# 

3201 

1600 

800 

400 

200 

100 

D 

3020 

1510 

755 

377 

189 

94 

D# 

2850 

1425 

712 

356 

178 

89 (90) 

E 

2690 

1345 

672 

336 

168 

84 (83) 

F 

2544 

1272 

636 

318 

159 

79 (80) 

F# 

2406 

1203 

601 

300 

150 

75 

G 

2267 

1133 

566 

283 

141 

70 

G# 

2140 

1070 

535 

267 

134 

67 (66) 

A 

2020 

1010 

505 

252 

126 

63 

A# 

1904 

952 

476 

238 

119 

59 (60) 

H 

1800 

900 

450 

225 

112 
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Die Werte in der 1. Oktave und die in der 6. Oktave in Klammer 
sind mit den Ohren und einem Synthesizer getestete Werte. Alle 
anderen Werte berechnen sich wie folgt: 

n te Oktave/2 = n-1 te Oktave 

Da ich alle Werte schon ausgerechnet habe, muß man diese nur 
ablesen. Diese Werte erzeugen auch als 12 Bit-Periodendauer, bei 
Direktprogrammierung des PSG, die jeweiligen Noten. Ist die 
Frequenz=>9000 wird die (Frequenz-9000)*256 als Rauschfre¬ 
quenz interpretiert, falls das Bit für Rauschen gesetzt ist. 
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Stärke: (8 Bit) 

Gibt die Stärke der Veränderung, die bei jedem Aufruf durch ’EVE- 
RY n GOSUB xyz’ erfolgt, des Tones durch die gesetzten Effekte 
an. 

Effekte: ( 8 Bit Wert) 

Bit 0, Frequenz erhöhen 
Bit 1, Frequenz niedriger 

Bit 2, Lautstärke größer (nicht bei Ringmodulation) 

Bit 3, Lautstärke kleiner (nicht bei Ringmodulation) 

Bit 4, Vibrato (Wellenform Dreieck) 

Bit 5, Ringmodulation 
Bit 6, Reserviert 

Bit 7, Rauschen (nicht bei Ringmodulation) 

Werden mehrere Bits gleichzeitig gesetzt, tragen diese Effekte ge¬ 
meinsam zur Klangbeeinflussung bei. 

Lautstärke (Velocity bzw. Amplitude): (8 Bit) 

Es sind Werte von 0-15 sinnvoll, gibt normalerweise die Lautstärke 
des gespielten Tones einer Stimme an. Wenn eine Stimme ringmo¬ 
duliert wird, gibt die Lautstärke die Art der Modulation an (Ausnah¬ 
me Lautstärke = 0), wobei 

0 = kein Ton (alle Stimmen aus) 

1 = Hüllkurve =12, Geschwindigkeit der Hüllkurve = Frequenz 

2 = Hüllkurve = 14, Geschwindigkeit der Hüllkurve = Frequenz 

3 = Hüllkurve = 14, Geschwindigkeit der Hüllkurve = Frequenz/48 

Wie sich die Ringmodulation anhört, kann man nicht beschreiben, 
das muß man einfach ausprobieren ! 
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4.5.2 Das Format meiner Song (.sng) Files 

Byte 0 - 7, Magic ’ST-MODUL’ 

Byte 7 - 15, Modul - Name 

Byte 16, Menge der Tracks bis 255 

Danach "Noten" im Format 

Stimme 1: Frequenz, Stärke, Effekt, Lautstärke 
Stimme 2: Frequenz, Stärke, Effekt, Lautstärke 
Stimme 3: Frequenz, Stärke, Effekt, Lautstärke 

pro Track 32 mal 


4.5.3 Die Programmierung der Soundroutine 

So eine Soundroutine ist eine relativ komplizierte Sache, ich habe 
selbst etwa eine Woche gebraucht ("ich habe zwischendurch auch 
mal was anderes getan als Programmieren"), um die für Argon 4 
fertigzustellen. Insofern möchte ich nicht jedes Detail dieser Routi¬ 
ne, die ja nur zur Anschauung dienen soll, erklären, sondern grund¬ 
sätzliche Techniken erklären. 


4.5.3.1 Abspielen der Musik parallel zum Programm 

Ein Programm ist normalerweise eine sequentiell abgearbeitete 
Reihe von Befehlen. 

"Wie soll denn da was parallel laufen ?" 

Da wir im Regelfall nur eine CPU in unserem ATARI haben und nur 
einen Bus zum Speicher, auf den nur ein Prozessor "gleichzeitig" 
zugreifen kann (ausgenommen FALCON030), ist es nicht möglich, 
eine Abfolge von Befehlen parallel zum Programm laufen zu lassen. 


60 



Ein komplettes Spiel 


Es gibt jedoch die Möglichkeit, den Prozessor kurzzeitig zu unter¬ 
brechen und ein paar weitere Befehle ausführen zu lassen, die 
nicht zum Hauptprogramm gehören, und dann am Hauptprogramm 
Weiterarbeiten zu lassen. Dies geschieht beim ATARI schon bei je¬ 
dem Tastendruck oder der Bewegung der Maus, da in diesem Fall 
der Tastaturprozessor (IKBD) via MFP (verwaltet die Interrupts 
und mehr) einen Interrupt auslöst und eine Routine ein Datenpaket 
vom IKBD abholt und verarbeitetT so daß z.B. der Mauspfeil beim 
nächten VBL (der auch einen Interrupt d.h. eine Unterbrechung 
auslöst) an neuer Position auf den Bildschirm gezeichnet wird. Die¬ 
ses kurzzeitige Unterbrechen des Prozessors kann man auch 
selbst hervorrufen, in dem man den MFP, der auch Timer (wie ein 
Wecker) Baustein ist, dazu gebraucht, den Prozessor alle paar Mil¬ 
lisekunden zu wecken (daran zu erinnern), etwas anderes zu tun. 
In unserem Fall macht dies das GFA - BASIC, das wiederum, 
wenn ein solcher Interrupt auftritt, ein Flag setzt und nach jedem 
BASIC Befehl testet, ob der Interrupt schon aufgetreten ist, also 
das Flag schon gesetzt ist, um dann in die angegebene Prozedure 
zu verzweigen. 

Die Syntax zum Setzen eines solchen Interrupts in GFA - BASIC 
sieht so aus, 

EVERY n% GOSUB xyz 

(wird mittels den 200Hz Sytem - Timer über den etv_timer $400 
Vektor realisiert) 

wobei die Zeit durch ’n%’ eingestellt werden kann, wenn ’n%=1’ 
dann wird theoretisch alle 1/200stel Sekunden ein Aufruf der Pro¬ 
zedure ’xyz’ vorgenommen. Die Zahl, die für ’n%’ eingesetzt wird, 
sollte nicht kleiner als vier sein. Aber selbst bei Werten größer vier 
kann es unter Umständen, wenn die aufgerufene Procedure "ex¬ 
trem" lang ist, zu Problemen kommen, da es möglich ist, daß die 
von 'EVERY ...’ aufgerufene Procedure selbst wieder unterbrochen 
wird und es durch Überschreiben von globalen Variablen oder ei¬ 
nem Stacküberlauf zu unvorhersehbaren Ergebnissen kommen 
kann. Ich habe diese Problem für meine Soundroutine, die doch 
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recht lang ist, gelöst, indem ich immer eine kleine Prozedure aufru- 
fe, die ein Flag setzt, das ich wieder durch ständiges Abfragen te¬ 
ste und entsprechend in meiner Soundroutine aufrufe. 

Damit man das ständige Aufrufen einer Procedure auch stoppen 
kann, bietet GFA - BASIC den ’EVERY STOP’ Befehl an. 


4.5.3.2 Das Abspielen mit dem Soundchip 

Es gibt in GFA - BASIC zwei Befehle, um den Soundchip zu pro¬ 
grammieren, diese basieren beide auf dem Dosound-Aufruf (XBIOS 
32) des Betriebssystems. Die zwei GFA - BASIC Befehle nennen 
sich 'SOUND' und ’WAVE’ 

SOUND kanal%, laut%, n ote%, okt%,verz% 

III I I_ warten verz% * 1/50 Sek. 


Oktave 1 bis 8 
Note 1 = C bis 12 = H 
Lautst. 0 bis 15 (laut) 
Tonkanal 0 bis 2 


hinter der Lautstärke kann anstatt Oktave und Note die Frequenz 
angegeben werden (siehe Tabelle in 4.5.3.1) in der Form gefolgt 
von einer Variablen oder Konstanten als Frequenz bzw. Vorteiler 
für den Soundkanal. Näheres dazu im Kapitel über Sounderzeu¬ 
gung. 
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WAVE stim%,huell%,form%,dauer%,verz% 

stim% Kanal an/aus Bit 0, Kanal 1 an 

Bit 1, Kanal 2 an 
Bit 2, Kanal 3 an 

Rauschen an/aus Bit 3, für Kanal 1 
Bit 4, für Kanal 2 
Bit 5, für Kanal 3 


dazu kann das 256 mal 0..31 addiert werden, um das Rauschfre¬ 
quenzspektrum festzulegen, was soviel bedeutet wie wenn im obe¬ 
ren Byte des Wortes Werte von 0 bis 31 stehen, diese die Rausch¬ 
frequenz angeben. 


huell% gibt an, welcher Kanal von der Hüllkurve beeinflußt 
wird. Belegung wie die untersten 3 Bits von ’stim%’. 

form% gibt die Hüllkurvenform an, siehe Kapitel 4.2.1 

dauer% 16 Bit-Wert in 0.128 ms Schritten, gibt die Länge der 
Hüllkurve an. 


Beispiel: 


SOUND 0,15,#1000 
SOUND 0,15,#1001 
SOUND 0,15,#1002 
WAVE 7,7,13,10000 


! Kanal 1 setzen 
!Kanal 2 setzen 
! Kanal 3 setzen 

! Alle an, Hüllkurve für alle, /—, 1,28 Sek. 


Spielt einen hübschen, langsam lauter werdenden dreistimmigen 
Klang; durch die sehr nah aneinander liegenden Frequenzen hört 
man eine starke Phasenverschiebung. Wichtig, immer erst 
'SOUND’ Befehle für die zu spielenden Kanäle setzen und dann 
erst mit dem 'WAVE' Befehl abspielen lassen. 
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4.6 Lesen der Cookies 


Ich stelle zuerst die Adresse der Cookies fest, falls diese Null ist, 
lösche ich ein Flag mit Namen ‘cookies!’. Falls die Adresse aber 
ungleich Null ist, wird das Flag gesetzt, und die Cookies werden 
langwortweise in einen String verfrachtet und über eine ’SELECT .. 
CASE Struktur auf für das Programm "wichtige" Inhalte geprüft und 
die Werte in Variablen mit Struktur Namen gespeichert (siehe dazu 
auch das Kapitel zur Kompatibilität). 


cookies%=LPEEK(&H5A0) Istellt Adresse der cookies fest 

> PROCEDURE cookies lAuswerten der cookies 
IF cookies%=0 
cookies!=FALSE 
ELSE 

cookies!=TRUE 

t%=cookies% 

WHILE LPEEK(t%)<>0 
text$=" H 

text$=M KL$( LPE E K(t%)) 

tt%=t%+4 

SELECT text$ 

CASE "_CPU B ! Welcher Prozessor 
cpu%=LPEEK(tt%) 

CASE "_FPIT ! Floating Point ? 
fpu%=DPEEK(tt%) 

CASE "_MCH M ! welche Maschine ST-TT-Falcon ? 
mch%=DPEE K(tt%) 

CASE "_SND" ! welcher Soundchip ? 
snd%=LPEEK(tt%) 

CASE "_VDO“! welche Videohardware 
vdo%= D P E E K(tt%) 

ENDSELECT 
ADD t%,8 
WEND 
ENDIF 
RETURN 


Ich teste z.B. über die Cookies, welcher Soundchip sich in dem 
Gerät, auf dem das Programm gerade läuft, befindet, um dann die 
DMA -Soundroutine zu laden und benutzen, anstatt der entspre¬ 
chenden Routine für den PSG . 
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4.7 Vorbereitungen für MULTI - TOS 

Ein Problem bei der Programmierung von ARGON 4 waren die 
ständigen Änderungen, die ich einerseits wegen MULTI - TOS und 
anderseits wegen dem Falcon030 vornehmen mußte. Betreffen die 
Änderungen wegen des Falcon nur das Sound - Subsystem, das 
sich wider Erwarten ohne vorherige Initialisierungen keineswegs, 
wie in den Medien angedeutet, kompatibel zum STE/TT DMA 
Sound verhält. Das MULTI TOS hingegen ist wider Erwarten kein 
EVENT-orientiertes Multi-Tasking (das Ablaufen mehrerer unter¬ 
schiedlicher Programme/Routinen im schnellen Wechsel) sondern 
ein Einteilen der Prozessorzeit in Zeitscheiben, so daß via Interrupt 
von einem zum anderen Prozess umschalten kann, so daß man 
das MULTI TOS nicht so einfach daran hindern kann, das Um¬ 
schalten der Prozesse sein zu lassen. Da ich nicht geplant hatte, 
ein Fenster zu öffnen, und ich trotzdem nicht wollte, daß ein ande¬ 
res Programm in den Bildschirmspeicher schreibt, habe ich diesen 
dauerhaft mit FORM_DIAL( 1 ) für andere AES Prozesse, mit 
FORM_DIAL(3) die Drop Down Menüs gesperrt und die Maus für 
meine eigenen Zwecke reserviert. Zuvor habe ich mit 

FORM_DIAL(0,...), den kompletten Bildschirm für meine Zwecke re¬ 
serviert. 

xres&=WORK_OUT(0) Maximale X Position 
yres&=WORK_OUT(1) Maximale Y Position 
VOID FORM_DIAL(0,0,0,xres&,yres&,0,0,xres&,yres&) 

VOID WIND_UPDATE(1) 

VOID WIND_UPDATE(3) 

Wenn ich das Programm beende, teile ich dem AES mit 

W1NDJJPDATE mit, daß mein Bildaufbau abgeschlossen ist und ge¬ 
be mit WIND_UPDATE(2 ) die Mauskontrolle wieder ans AES oder 
einer anderen laufenden Applikation zurück. Mit FOR_DIAL(3,...) 
gebe ich den reservierten Bildschirmbereich wieder frei und das 
AES sendet an alle laufenden Applikationen, daß sie die Fensterin¬ 
halte wieder auffrischen sollen. 

VOID WIND_UPDATE(0) 

VOID WIND_UPDATE(2) 

VOID FORM_DIAL(3,0,0,xres&,yres&,0,0,xres&,yres&) 


65 



Spiele selbst programmieren 


Mit diesen Maßnahmen verhindere ich, daß die Drop Down Menüs 
herunterklappen oder eine andere Applikation in den Vordergrund 
kommt und in den Bildschirmspeicher schreibt. Alle grafischen 
Prozesse sind gesperrt, weil ich die Ausgabe auf den Bildschirm 
für andere Programme gesperrt habe, diese somit auf das Ende 
meines Programms warten müssen. 
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4.8 Anpassung des Programms an die 
Geschwindigkeit des Rechners 

Es gibt mehrere Möglichkeiten, ein Programm an die Geschwindig¬ 
keit des Rechners anzupassen; ich habe bei ARGON 4 eine relativ 
einfache gewählt! 

Die Procedure ’scroll’ erzeugt im Speicher einen etwa 320 Pixel 
breiten aber mehrere Bildschirme langen Block, dieser wird dann 
mit dem ’BMOVE’ Befehl jeweils als Hintergrund in einen der drei 
Pufferspeicher, von denen einer zu sehen ist, kopiert. Zum Erzeu¬ 
gen dieses BLocks wird der RCjCOPY aus GFA - Basic benutzt. 
Da ich diesen Befehl auch zum Kopieren der Sprites benutze, mes¬ 
se ich die Geschwindigkeit dieses Vorgangs und die Geschwindig¬ 
keit, die der Rechner für 20000 Leerschleifen benötigt (in Procedu¬ 
re ’speed’). Das Messen der Zeit von Leerschleifen und Blockauf¬ 
bau erfolgt über den Befehl 'TIMER' welcher die Systemzeit seit 
dem Einschalten in 1/200 Sekunden zurückgibt und wahrscheinlich 
BIOS(6) also ’Tickcal’ benutzt. 

Handhabung: 

zeit%=TIMER 

! Das wird gemessen 


zeit%=TI M ER-zeit% 


’zeit%’ enthält dann die benötigte Zeit in 1/200 Sekunden. 


In der Procedure ’main’ wird eine Leerschleife ausgeführt, die die 
Menge der ausgeführten Durchläufe aus dem Quotienten der ge¬ 
messenen Zeiten bei ’scrolC und ’speed 1 errechnet wurde. 
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speed%=(( 126-zeit%)/(zeit2%/200)) 

II I I 

I I I I_konstanter Faktor zur Anpassung 

I I I 

I I I_Zeit für Leerschleifen 

I I 

I I_Zeit zum Aufbau des Scrollblocks 

I 

I_Zeit zum Aufbau des Scrollblocks 

auf einem normalen ST 


Die Formel habe ich so aufgestellt, daß bei einem normalen ST oh¬ 
ne Blitter ’speed%’ einen Wert kleiner gleich Null enthält. Diese Art 
der Geschwindigkeitsanpassung hat unter einem Multitasking Be¬ 
triebssystem einen großen Nachteil, da die nicht benötigte Rechen¬ 
zeit durch die Leerschleife "verheizt" wird und nicht anständig ge¬ 
nutzt wird. Daher sollte man idealer Weise EVNT_TIMER also AES 
24 benutzen und eine Wartezeit in Millisekunden angeben, diese 
Funktion teilt die nicht benötigte Rechenzeit z.B. einem Accessory 
zu. Da mein Spiel vom AES des MULI - TOS eher gestört wird, da 
ja alles so gleichmäßig wie möglich ablaufen soll und mein Spiel 
keine "reguläre" GEM-Applikation ist, lasse ich die Leerschleife im 
Programm. 

Eine andere Möglichkeit, Spiele rechnergeschwindigkeitsunabhän¬ 
gig zu schreiben, ist, die Bilschirmausgabe mit dem VBL zu sync- 
ronisieren, d.h. erst nach dem nächsten VBL (oder mehreren fest 
definierten VBL’s) die Sprites und den Hintergrund neu zu plazie¬ 
ren. Diese Methode ist nur bei extrem maschinennaher Program¬ 
mierung sinvoll und für mich (bei ARGON 4) nicht in Frage gekom¬ 
men. Diese Methode hat jedoch das Problem, daß die Bildwieder¬ 
holfrequenz schon bei normalen STs unterschiedlich sein kann 
(50Hz, 60Hz und 71 Hz), also das Spiel schon dann schneller oder 
langsamer wird, was mir bei einigen Spielen auch schon aufgefallen 
ist. Extrem auffällig ist dieses Problem beim Abspielen von Musik 
im VBL, wenn man das entsprechende Programm zum Abspielen 
mal bei 70Hz startet. Hier ist die Lösung, den 200Hz Timer oder 
andere freie Timer zur Syncronisierung des Programms, nicht nur 
beim Abspielen von Musik, zu verwenden. 
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4.9 Die Maschinenroutinen 

Ich brauche für dieses Spiel, wie schon erwähnt, vier Maschinen¬ 
routinen. Die Routinen sind alle Postition Independent d.h. sie kön¬ 
nen an jede beliebige Stelle im Speicher geladen und gestartet wer¬ 
den, mit Ausnahme der DMA Routine, diese läuft nur im ST - RAM. 
Ich werde an dieser Stelle die Maschinenroutinen nicht komplett er¬ 
klären, da ich dem Leser erst im nächsten Kapitel die nötigen 
Kenntnisse in Maschinensprache vermittele. Im zweiten Teil des 
Buches werde ich mich näher mit der direkten Programmierung der 
Hardware beschäftigen, mit dem Inhalt des zweiten Teils dürfte die 
Funktion der Routinen dann "hoffentlich" klar werden. Naja, die sind 
auch nicht ganz so einfach zu verstehen, trotzdem habe ich nichts 
dagegen wenn jemand sie in eigenen Programmen benutzt, selbst 
wenn er nicht versteht, wie sie funktionieren. Die Routinen sind na¬ 
türlich alle als dokumentierte Listings auf Diskette. 

4.9.1 Erzeugen der Maske 

Die einfachste Routine war eigentlich mal für ein Zeichenpro¬ 
gramm, das ich schreiben wollte, gedacht. 

Was macht sie ? 

Diese Routine holt sich mit Logbase (XBIOS 3) die logische Bild¬ 
adresse, das ist die Adresse, auf die alle LINE A-Aufrufe erfolgen. 
In einer Schleife werden dann die vier Bitplanes des Bildschirms 
’or’ verknüpft, invertiert und auf den Bildschirm zurückgeschrieben, 
Wort für Wort. Diese Routine ist nicht besonders optimiert, aber 
dafür leicht verständlich. 

Wie benutzt man sie: 

- man kopiert die Sprites, für die man die Maske braucht, in einen Speicher 

- setzt mit ’setscreen’ ’Logbase’ auf diesen Speicher 

- und ruft die Routine mit einem ’call anfangsadresse%’ auf. 

BMOVE sprite%,maske%,32000 
VOID XBIOS(5,L:maske%,L:-1,-1) 

CALL white% ! Assembler Teil zum Erzeugen der Maske 
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4.9.2 Umschalten der Palette 

Wie man sieht, existieren bei ARGON 4 zwei Paletten, die Um¬ 
schaltung erfolgt während des VBL und an der 180. Zeile. Dabei 
werden 14 Register (alle außer Hintergrund und Farbe 0) gewech¬ 
selt. 

Was macht sie ? 

Installiert eigene VBL Routine, die dann die ursprüngliche VBL- 
Routine aufruft und TIMER B setzt, um an Zeile 170 einen Interrupt 
auszulösen. Initialisiert TIMER B via Xbtimer (XBIOS 31). 

Die TIMER B Interruptroutine wartet auf Zeile 180 und setzt die 
Palette. In einem Programm, das diese Routine nutzt, muß das In¬ 
terrupt Vektor Register auf Automatic End of Interrupt gestellt sein. 

vr%=&HFFFFFA17 llnterrupt Vektor Register 

SPOKE vr%,BCLR(PEEK(vr%),3) lAutomatic End of Interrupt 

Wie benutzt man sie ? 

- man dimensioniert eine Variable für RCALL, z.B.: DIM reg%(16) 

- man rette alte VBL Adresse 

oldvec%=BIOS(5,28,L:-1) lalter VBL Vector 

- ruft die Routine auf, z.B. mit: RCALL chcoll%,reg%() 

- dann bekommt man in reg%(8) und reg%(9) die Adressen der zu 
wechselnden Palettenpuffer zurück 

- und kopiert die zu wechselnde Paletten in die Puffer 

BMOVE palettel%,reg%(8),28 
BMOVE palette2%,reg%(9),28 

falls man sie nicht schon zuvor richtig initialisiert (mit den richtigen 
Werten belegt hat). 
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4.9.3 Abspielen digitalisierter Klänge mit dem PSG 

Diese Routine habe ich nicht selbst geschrieben, sie ist von Kay 
Römer, der gut optimierten Assembler-Code programmiert, also ei¬ 
ne gute Wahl als Autor einer solchen Routine. Diese Routine spielt 
zweistimmigen YAMAHA-Sound mit etwa 6 kHz Abspielfrequenz 
ab und benötigt ca. 22% der Rechenzeit auf einem 8 MHz ST. 

Was macht sie: 

Ein Einsprung in die Routine mit einem Offset von 110 Bytes initia¬ 
lisiert den Soundchip und richtet mit Xbtimer (XBIOS 31) den Timer 
A auf die eigenTliche Abspielroutine. Dann, bei jedem regulären 
Aufruf (Offset 0), und der Übergabe von Anfangs- und Endadresse 
des zu spielenden Samples, werden bis zu zwei Samples (digitali¬ 
sierte Sounds) gespielt. 

Wie benutzt man sie: 

- Initialisieren, RCALL startadr%+110,reg%() 

- Aufrufen, Sample Startadresse in reg%(6), Endadresse in reg%(7) 

RCALL startadr%,reg%() 
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4.9.4 Abspielen digitalisierter Klänge via DMA - 
Sound 

Diese Routine ist ein zweistimmiger Sample Player, wobei jede 
Stimme die volle 8 Bit Auflösung hat, da ich die zwei Samples auf 
den linken und rechten Kanal verteile. Die Abspielfrequenz beträgt 
12,5 kHz, verbrauchte Rechenzeit wohl unter 10%. 

Was macht sie: 

Bei einem Aufruf mit dem Offset 0 wird der DMA - Sound Initiali¬ 
siert, wobei wiederholt ein Puffer abgespielt wird. Wenn kein Sound 
mehr abgespielt werden soll, wird der Puffer mit Nullen gefüllt. Per 
Xbtimer (XBIOS 31) wird der Timer A auf die Abspielroutinen gerich¬ 
tet und so eingestellt (EVENT COUNT), daß er einen Interrupt 
auslöst, wenn der DMA-Abspieler am Ende des Puffers ist. Die 
Abspielroutine selbst holt jeweils ein Langwort von einem Sample 
und ein Langwort vom anderen Sample und schreibt diese um je ein 
Byte versetzt in den jeweiligen Puffer. Dieser Puffer wird vom 
DMA - Sound - Subsystem in Stereo abgespielt, wobei die Bytes 
an den geraden Adressen auf dem linken und an den ungeraden 
Adressen auf dem rechten Kanal abgespielt werden. Den Ende ei¬ 
nes Samples erkennt die Routine, wenn das Sample ein Langwort 
mit Null enthält. 

Wie benutzt man sie: 

- initialisieren mit RCALL startadr%,reg%() 

- Aufrufen, Sample Startadresse in reg%(6), 

in reg%(5), 0 = linker u. 4 = rechter Kanal dann 
RCALL startadr%+48,reg%() 
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4.10 Tips zu ARGON 4 

Wie man sieht, ist ein komplettes Spiel schon eine komplexe Sa¬ 
che; die Programmierung eines solchen Spiels für Anfänger kom¬ 
plett zu erklären, ist fast unmöglich. Einige mögliche Fragen kann 
und will ich erst im zweiten Teil eines Buchs erklären, auch wenn 
ich im zweiten Teil des Buchs nicht mehr direkt auf Argon 4 einge¬ 
he, sind viele Verfahren erklärt, die ich bei der Programmierung 
des Spiel gebraucht habe. Vieles im Programm ist auf Geschwin¬ 
digkeit optimiert, aus diesem Grund benutze ich nur globale Varia¬ 
blen, weil der Zugriff auf diese in GFA - BASIC 3.X einfach schnel¬ 
ler ist als auf locale und ich dann den Compiler so einstellen kann, 
daß das erstellte Programm die Prozeduren direkt als Maschinen¬ 
routinen anspringt, was wiederum zu schnellerem Ablauf führt. 
Letztendlich ist in diesem Fall auch der Forschergeist des Lesen¬ 
den gefragt; einfach ein Backup des Argon 4 Listings machen und 
damit herumspielen, das ist sicherlich interessanter als alles nach- 
lesen zu müssen. 
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A.5. Einführung in die Assemblersprache der 
680X0 Prozessoren 

Einleitung 

Obwohl heutige Homecomputer schon "sehr schnell" sind, reicht oft 
die Geschwindigkeit von Hochsprachen wie C, Pascal und Basic 
nicht mehr aus, um komplexe Spiele mit riesigen Sprites oder re¬ 
chenintensive Simulationen zu schreiben. Je höher der Standard 
bei den Spielen wird, desto tiefer müssen wir, die Programmierer, 
bei den "kleineren" Geräten auf die System - Ebene herunter stei¬ 
gen um die Leistung, die wir für dessen Realisation benötigen, dem 
Rechner zu "entlocken". 

Was ist Assembler ? 

Assemblercode ist die dem Menschen “verständliche" Form der 
Maschinensprache, wobei der Assembler ein Programm ist, der 
diese Sprache in die vom Prozessor verständliche Form umwan¬ 
delt. Danach wird dieser sogenannte Objekt Code von einem Linker 
zu einem ausführbaren Programm gemacht. 

Dem Anfänger empfehle ich den TurboAss von Sigma - Soft als 
Assembler zu nutzen, denn er ist ein Shareware Programm und in 
diversen PD-Pools erhältlich, wenn er ihnen jedoch gefällt, sollten 
sie sich fairerweise registrieren lassen !!! 

Der Assembler von Sigma - Soft mahnt die Syntax - Fehler schon 
beim Schreiben, was ihn für Anfänger besonders wertvoll macht 
und viel Zeit bei der Fehlersuche erspart. 
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Die 680X0 Prozessoren 

Zeittafel 


1979- 

68000 

1983- 

68010 

1985- 

68020 

1987- 

68030 

1989- 

68040 

etwa 1994 - 

68060 


5.1 Aufbau des Prozessors (ein "bißchen” zum Einstieg) 

5.1.1 Die Daten/Adressregister 

Die Prozessoren der 68000 Familie besitzen 8 Daten (DO - D7) und 
8 Adressregister (A0 - A7). Die Datenregister kann man sich als 
Integervariablen vorstellen, sie sind 32 Bit breit, d.h. ein komplettes 
Langwort paßt in je ein Register. Das ist schon beim MC 68000 so, 
obwohl er "nur" einen 16 Bit breiten Datenbus hat, d.h. er muß, um 
ein Register zu füllen zweimal auf den Speicher zugreifen, denn die 
Busbreite gibt an, wieviel Bit der Prozessor bei einem (!) Zugriff 
auf den Speicher erhält. Alle Prozessoren ab dem 68020 haben ei¬ 
nen 32 Bit Datenbus, sie können auf 16 Bit genauso schnell zugrei¬ 
fen wie auf 32 Bit. Die Adressregister wiederum kann man sich als 
"Zeiger" auf einen bestimmten Speicherbereich vorstellen. Auch sie 
müssen 32 Bit breit sein, damit sie auf jede beliebige Adresse im 
Speicher zeigen können. Zwar kann der 68000 nur Adressen bis zu 
einer Größe von 24 Bit (ca. 16.7 Millionen) verwalten, aber ab dem 
68020 kann die 680X0 Familie mehrere Gigabytes verwalten. 

Das richtige Nutzen von Registern kann einen großen Gewinn an 
Rechengeschwindigkeit bedeuten, da der Prozessor die für die Be¬ 
fehle benötigten Daten nicht mehr aus dem Speicher "nachladen" 
muß, und jeder Zugriff auf den Speicher braucht Zeit. 
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5.1.2.1 Das Adressregister A7 - der Userstack 

Das achte Adressregister ist etwas ganz besonderes, man nennt 
es Stackpointer d.h. einen Zeiger auf den Stack. Der Stack oder 
Atic ist ein Stapelspeicher. Der Stack wächst von oben nach unten 
und der Stackpointer (A7) zeigt (wenn alles gut geht) immer auf 
das momentane Ende des Stacks. Man könnte theoretisch jedes 
beliebige Adressregister als Stack benutzen, allerdings gibt es be¬ 
stimmte Befehle, die nur auf den Stack zugreifen, die in ihrer Aus¬ 
führungszeit optimiert sind. Zudem wird auf dem Stackpointer die 
Rücksprungadresse, bei einem möglichen Aufruf einer Unterrouti¬ 
ne, abgelegt, das ist so ähnlich wie der Aufruf einer Procedure in 
GFA - Basic. 


5.1.2.2 Das Adressregister A7’ - der Supervisorstack 

Zuerst muß ich mal erklären, was der Supervisormode ist. Der Su¬ 
pervisormode ist die Betriebsart, in der das Programm auf das 
komplette System zugreifen darf, d.h. alle möglichen Speicherbe¬ 
reiche schreiben und lesen darf. Zudem kann man bestimmte Be¬ 
fehle nur im Supervisormodus ausführen. Normalerweise befindet 
sich der Atari im Usermode, in dieser Betriebssart sind bestimmte 
"lebenswichtige" Speicherbereiche vom Programm (selbst bei ei¬ 
nem Fehler) nicht zu erreichen, das bedeutet einen relativ sicheren 
Schutz vor einem Systemabsturz. Zu den Aufgaben, die der Stack 
im Usermode hat, wird er im Supervisormode, bei Interrupts, als 
Ablage vom Status des Prozessors gebraucht. Bei Prozessoren ab 
68020 gibt sogar zwei Supervisorstackpointer ISP (Interruptstack¬ 
pointer) und MSP (Masterstackpointer). Der ISP hat dieselben 
Aufgaben wie der SSP (Supervisorstackpointer) beim 68000, der 
MSP ist eigentlich gedacht, um dem Betriebssystem einen eigenen 
Stack zu erlauben, der sich auch während eines Interrupts nicht 
ändert. 
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Achtung ! der Stackpointer (sowohl USP, SSP.ISP als auch MSP) 
zeigt immer auf eine gerade Adresse (das unterste Bit wird nicht 
ins Register übernommen), das ist der Hauptunterschied zu den 
anderen Adressregistern. 


5.1.3 Das Statusregister 

Das Statusregister ist ein 16 Bit breites Register und besteht aus 
zwei Teilen. Der obere Teil besteht aus den Trace Bits, dem Supe- 
visor Bit, Master/Interrupt Status Bit und der Interrupt Maske, läßt 
sich nur im Supervisormode des Prozessors manipulieren, dieser 
Teil wird System-Byte genannt; mit ihm werde ich mich noch be¬ 
schäftigen. Der untere Teil, das Condition Code Registe CCR oder 
User-Byte, kann in allen Prozessorbetriebsarten beschrieben und 
gelesen werden. Das CCR besteht aus dem Extented, Negativ, 
Zero, Overflow und dem Carry-Flag. Diese Flags sind Bits, die 
beim Eintreten bestimmter Situationen vom Prozessor gesetzt 
werden. 


Diese Flags werden z.B. gesetzt, wenn: 


eXtented Flag ähnlich Carry Flag, wird aber bei bestimmten Be¬ 
fehlen z.B. addx, subx, rox ... bei der Ausführung 
des Befehls berücksichtigt. 

Negativ Flag wenn bei einer Subtraktion das Ergebnis negativ 
wird. 


Zero Flag wenn beim Bewegen eines Werts vom Speicher in 

das Register der übertragene Wert Null ist. 

Overflow Flag wenn bei einer Division der Dividend kleiner als 
der Divisor ist. 


Carry Flag wenn bei einer Addition die Größe des Zielregi¬ 
sters überschritten wird. 


Das waren die für den Einsteiger wichtigsten Register, kommen 
wir nun zu den Adressierungsarten. 
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5.2. Die Adressierungsarten des 68000 

(die zusätzlichen Adressierungsarten der Prozessoren ab 68020 
behandele ich erst am Ende des Kapitels) 

5.2.1 Register direkt 

"Register direkt" bedeutet direkt in ein Register (gehe nicht über 
Los und ziehe nicht 4000 Mark ein). 

MOVE.L AI ,A2 oder 

MOVE.L D2,D1 oder 

MOVE.W D1,A5 

ist Register direkt ! Es wird ein Wert direkt von einem zu einem 
anderen Register übertragen. 

Auch 
CLR.L DO 

ist Register direkt, denn das angegebene Register wird gelöscht 
(CLR Abkürzung für CLeaR). Wenn es ein "direkt" gibt, gibt es auch 
ein indirekt! 


5.2.2 Adressregister indirekt 

(Register Indirect Addressing) 

MOVE.L (A0),D0 

bewege das, was in der Adresse steht (.L steht für Langwort und 
bewegt volle 32 Bit), auf die das Register ’A0‘ zeigt in Register ’DO’ 

- also "durch die Brust ins Knie". 

- mit Postinkrement (Erhöhung danach) 
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MOVE.L (AO)+,DO 

ähnlich wie oben, jedoch wird nach der Operation der Inhalt von 
’AO’ um 

- <Befehl>.L 4 Bytes - Befehl benutzt 32 Bit Daten 

- <Befehl>.W 2 Bytes - 16 Bit Daten 

- <Befehl>.B 1 Byte - 8 Bit Daten 

weitergezählt, also um genau so viele Bytes, wie wir übertragen 
haben, das ist ideal zum Kopieren von Speicherbereichen (wenn 
man ausreichend Register frei hat, ist ein MOVEM zum Kopieren 
von Speicherbereichen schneller! Dazu später mehr). 

wo es ein Plus gibt, gibt es auch ein Minus 

- mit Predekrement (erniedrigen davor) 

MOVE.L -(AO),DO 

zieht je nach übertragenen Byte(s) (.B .W .L), ein, zwei oder vier 
Byte(s), vor der Ausführung des MO VE Befehls vom Adressregi¬ 
ster ab. 

"Also das Ganze nur andersherum !!!" 

- mit Adressdistanz 

MOVE.L -200(A0),D0 
I 

I_Offset, darf nicht größer werden wie 16 Bit, 

signed Integer (+32768 bis -32767) 

die Adresse, von der in diesem Fall übertragen würde, errechnet 
sich aus dem Inhalt des Adressregisters+Offset. Nehmen wir an, 
der Inhalt von AO wäre ’2000’, so würde der Prozessor dann ’200’ 
von ’AO’ abziehen also '2000-200’ -> also ’1800’ und würde den In¬ 
halt dieser Adqresse in das Adressregister ’DO’ kopieren. 
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Das geht natürlich noch etwas “ausgefeilter"! 

- mit Adressdistanz und Index 

MOVE.L 100(A0,D0.X),1040 
I I I 

I I I_ ’.W’ 16Bitund’.L’ 32 Bit Vorzeichen 

I I behaftete Werte im Indexregister 

I I 

I I_ Indexregister 

I 

I 

I_ Offset von "leider nur" -128 bis +127 

MOVE.L 100(A0,D0.X),1040 


5.2.3 Absolute Adressierung 

- Absolut lang 

(Absolute Data Addressing Long) 

MOVE.L 520,700000 
I I 

I_I_32 Bit Wert 

dieser Befehl überträgt das an der Adresse ’520’ stehende Lang¬ 
wort, also die Bytes von 520 bis 524, an die Adressen 1040 bis 
1044. Diese Art der Adressierung ist "1. Eine Speicherverschwen¬ 
dung", da der Befehl zusätzlich zwei Langworte enthalten muß und 
daraus resultiert "2. Seine geringe Ausführungsgeschwindigkeit", 
da der Prozessor beim Einladen der vielen Wörter (Befehlswort 
und Daten bzw. Adressen) auf den Speicher zugreifen muß und 
das ist für den Prozessor immer die Operation, für die er "extrem" 
lange braucht (abgesehen von einer Multiplikation). Allerdings ist 
diese Operation, beim Übertragen einzelner (nicht zusammenhän¬ 
gender) Inhalte von Adressen, schneller als wenn man jede Adres¬ 
se erst in ein Register und dann das Register indirekt kopiert. 
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- Absolut kure 

(Absolute Data Addressing short) 

MOVE.L d1,128.w 
I I 

I I_ .w gibt an, daß es sich um einen vorzeichen- 

I behafteten 16 Bit Wert handelt 

I 

I_ 16 Bit Wert 


Diese Art der Adressierung ist etwas schneller als die absolute 
Adressierung mit einem Langwort als Adresse (zumindest für einen 
68000), da der Prozessor nur einmal auf den Speicher zugreifen 
muß, um die Adresse zu laden und nicht zweimal. 


5.2.4 Konstanten Adressierung 

(Immediale Addressing) 

MOVE.L #12345678,D0 
I 

I_Wichtig ! den sonst wird die nachfolgende Zahl 

vom Assembler als Adresse und nicht als Konstante 
Interpretiert. 

bewegt die Zahl '12345678’ in das Datenregister 'DO' 
oder 

move.b #'K’,D0 

bewegt den ASCII-Code von "K" in DO, wobei die Hochkommas 
anzeigen, daß es sich um ein Zeichen handelt. 
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5.2.5 PC relative Adressierung 

(Program Counter Relative Addressing) 


'PC' ist die Abkürzung für Program Counter, das ist sozusagen ein 
Zähler im Prozessor, damit dieser auch immer weiß, wo er sich 
gerade im Programm (also im Speicher) befindet. 

Die PC relative Adressierung bedeutet im Prinzip, daß man bei Be¬ 
fehlen nicht absolute Adressen angibt sondern nur noch die Distanz 
zu der gewünschten Adresse. Damit ist es möglich, sogenannten 
"Position independent code" zu erzeugen, was nicht mehr und nicht 
weniger ist als ein Programm, das, ohne daß man seine Adressen 
an den jeweilgen Speicherbereich anpaßt (das macht normalerwie¬ 
se das Betriebssystem mit der vor dem Programm befindlichen 
Reloziertabelle), gestartet werden kann, was wiederum bedeutet, 
daß man es auch mal eben in einen anderen Speicherbereich ko¬ 
pieren und starten kann. Die ganzen Programme, die in GFA - Ba¬ 
sic als INLINE laufen (siehe auch Argon 4) müssen z.B. PC relativ 
geschrieben sein, da GFA - Basic beim Start eines Programms die 
INLINES nicht relozieren kann. Man kann natürlich versuchen, das 
selbst zu übernehmen. Ein weiteres Beispiel für PC relative Pro¬ 
gramme sind Programme, die im Bootsektor stehen z.B. die Nach¬ 
richt eines Virenschutzes im Bootsektor oder eben die Viren selbst. 
Diese müssen relativ sein, da z.B. nicht genügend Platz für eine 
Reloziertabelle im Bootsektor ist und niemand genau weiß, wohin 
der Bootsektor im Rechner XYZ geladen wird. 

- PC relativ 
MOVE.L 3200(PC),D0 

nehmen "wir" an, das Programm würde an der Adresse 5000 lie¬ 
gen, dann würde in unserem Beispiel der Inhalt von der Adresse 
8200 in das Register DO kopiert werden. 
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- PC relativ indiziert mit Adreßdistanz 


MOVE.L $20(PC,D0.X),A1 


I 

I 


W = Wort /L = Langwort 
von -127 bis +128 


Ähnlich wie Adressregister indirekt mit Adressdistanz und Index, 
allerdings wird statt einem Adressregister der Programmcounter 
als Basis für die Berechnung der Adresse genutzt. 
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5.2.5 PC relative Adressierung 
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- PC relativ indiziert mit Adreßdistanz 


MOVE.L $20(PC,D0.X),A1 
I I 

I I_ W = Wort /L = Langwort 

I 

I_ von -127 bis +128 


Ähnlich wie Adressregister indirekt mit Adressdistanz und Index, 
allerdings wird statt einem Adressregister der Programmcounter 
als Basis für die Berechnung der Adresse genutzt. 
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5.3 Der Einstieg in die Programmierung 

Genug der grauen Theorie ! 

Jetzt etwas Praxis ! 

5.3.1 Aufruf einer Betriebssystem Routine 

Das Betriebssytem TOS (Tramiel Operating System - "Tramiel’s 
Betriebssystem"), möchte in vielen Fällen die Übergabewerte auf 
den Stack übertragen haben, an dieser Stelle zeige ich Ihnen, wie 
das geht. 

Zuvor ein paar Regeln zur Syntax 
hinter einem 

’; ’ oder folgt ein Kommentar, wird vom 
Assembler ignoriert 
’ # ’ folgt eine Konstante 

z.B. ’A’, ein so "geklammertes" Zeichen wird in einen 
ASCII-Wert gewandelt 

’NAME:’ ist ein Label und wird vom Assembler in eine absolute 
Adresse gewandelt, kann auch PC-relativ verwendet 
werden. 


Es ist möglich, in Assembler z.B. "Worten" bestimmte Werte zuzu¬ 
weisen, 

Z.B. ZWEI EQU 2 

oder, je nach Assembler zwei = 2 

Lesen Sie dazu bitte entsprechendes Kapitel in Ihrem Assembler¬ 
handbuch. 
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****** Beispiel ****** (ASM1 .S in KAPA5.T0S auf der Diskette) 
; Programm zum Ausgeben eines Zeichens 

GEMDOS EQU 1 
CONOUT EQU 2 


MOVE.W #’A\-(SP) 

; legt den ASCII-Wert von A auf den 
; Stack 

MOVE.W #CONOUT,-(SP) 

; schreibt die Funktionsnummer auf 
; den Stack 

TRAP #GEMDOS 

ADDQ.I #4,SP 

; ruft das Betriebssystem 
; setzt den Stackpointer wieder 
; auf seinen alten Wert 


Raus aus dem Programm (QUIT) 


CLR.W -(SP) 

; übergibt 0 auf den Stack 
; entspricht 'MOVE.W #0,-(SP)’ 

TRAP #GEMDOS 

; ruft das GEMDOS 

.END 



Gehen wir mal genauer auf das kleine Programm ein, 

MOVE.W #'A’,-(SP) 

es zieht zuerst 2 Bytes vom Adressregister ’A7’ (auch ’SP’ also 
Stackpointer) ab und legt den ASCII-Wert von ’A’ (das umwandeln 
erledigt der Assembler) in die Adresse, auf die ’A7’, also der 
Stackpointer (auch ’SP’) zeigt, ab. Siehe dazu auch Adressregister 
"Indirekt mit Predekrement" und Konstanten-Adressierung. 
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Der nächste Befehl 

MOVE. W #CONO UT,-(SP) 

legt in gleicher Weise die Funktionsnummer der Betriebssystem¬ 
routine auf den Stack (der Bereich, auf den der Stackpointer zeigt). 

Der 

TRAP #GEMDOS 

ist der Aufruf der Exception (Ausnahme). Beim MC68000 liegt in 
den unteren 256 Bytes des adressierbaren Speichers eine Vektor¬ 
tabelle, bei einem Interrupt (Unterbrechung) wechselt der Prozes¬ 
sor in eine Ausnahmeverarbeitung und springt an die Adresse, die 
an der für diesen Trap vorgesehenen Adresse eingetragen wurde 
(z.B. durch das Betriebssystem). An dieser Adresse befindet sich 
der sogenannte Trap Dispatcher (Dispatcher = Verteiler), dieser 
wiederum liest die Funktionsnummer vom Stack und verzweigt in 
die entsprechende Betriebssystemroutine. Die wiederum nimmt 
(kopiert) die für sie bestimmten Daten vom Stack und verrichtet ih¬ 
re Arbeit, in unserem Fall kopiert sie die Bitmap des Buchstaben 
’A’ auf den Bildschirm. 

Um den Stackpointer, den wir in seiner Lage verschoben haben, 
wieder auf seine ursprüngliche Position zu bringen, addieren wir die 
Menge der auf den Stack plazierten Bytes, um den wir ihn nach un¬ 
ten verschoben haben, wieder mit 

ADDQ.l #4,SP 
I 

I_Das ’Q’ geht nur, solange sich die zu addierende (oder 

subtrahierende ’SUBQ’) Konstante (!) sich im Bereich 
von 0-8 befindet. Bei ’MOVEQ’ können signed 8 Bit 
große Konstanten übertragen werden. 


auf ihn drauf. 
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5.4 Das Umschalten in den Supervisor Mode 

Wenn man sich im User-Mode befindet, ist die Welt noch in Ord¬ 
nung, Systemabstürze kommen nur gelegentlich vor und auf die 
gefährlichen Speicherbereiche ganz weit oben (Hardwareregister) 
und ganz weit unten (Interrupt-Vektoren, System-Variablen) darf 
man eben nicht zugreifen ! 

Aber das soll sich jetzt ändern !!! 

Beim Einschalten des Computers oder nach einem Reset befindet 
sich der Rechner automatisch im Supervisormode; zu diesem Zeit¬ 
punkt trägt das Betriebssystem sich in die Interuptvektoren des 
Betriebssystems ein, und initialisiert die Hardwareregister (d.h. 
trägt eine Grundeinstellung ein). Dann schaltet das Betriebssystem 
in den Usermode und jedes dann gestartete Programm befindet 
sich im Usermode. Jedoch jede Routine, die im Interrupt ausge¬ 
führt wird, befindet sich im Supervisormode. Es wäre nun möglich, 
sich in einen Interruptvektor einzutragen und dann diesen Interrupt 
zu erzeugen. Im Usermode kann man sich jedoch in keinen Inter¬ 
ruptvektor eintragen ! Die einzige Möglichkeit, in den Supervisor¬ 
mode zu wechseln, ist das Betriebssystem, denn das 'hängt’ ja 
schon in einigen Vektoren. 
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5.4.1 Umschalten in den Supervisor-Mode 

Beispiel 

;Programm zum Umschalten in den Supervisor Mode 

;in KapitelÖ.TOS Datei ASM2.S 

;****** Von User in den Supervisor Mode ******* 

TEXT 

GEMDOS EQU 1 
SUPER EQU 20 

CLR.L -(SP) 

MOVE.W #SUPER,-(SP) ; Funktionsnummer auf den Stack 
TRAP #GEMDOS ; GEMDOS TRAP 
ADDQ.L #6,SP ; Stack auf alten Wert 

,************************************* 

;ln ’DO’ befindet sich jetzt der User Stackpointer 

;****** Rette a j ten Stackpointer ******** 

MOVE.L DO.OLDSTACK(PC); User Stackpointer retten 
.**************************************** 


Ab jetzt Supervisormode ! 

Hier kann man jetzt z.B. Auf die Hardwareregister zugreifen 
oder die Systemvektoren 
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;******* Zurück in den Usermode ******** 


MOVE.L OLDSTACK(PC),-(SP) 

MOVE.W #SUPER,-(SP) 

TRAP #GEMDOS 
ADDQ.L #6,SP 


Alten Stackpointer 
auf Stack 

Funktionsnummer auf Stack 
GEMDOS TRAP 
Stackpointer auf alte 
Position 


**************************************** 


******* 


QUIT ****** 


CLR.W -(SP) 
TRAP #GEMDOS 


; Funktionsnummer auf Stack 
; GEMDOS TRAP 


DATA ; Gibt an, daß jetzt nur noch Daten kommen, wird 
; vom Betriebssystem angelegt und nicht mit dem 
; Programm abgespeichert 


OLDSTACK: DS.L 1 ; Ein Langwort für alten Stackpointer 

; reservieren 


Sofern das Programm komplett im Supervisor Mode ablaufen soll, 
ist diese Art der Umschaltung sinnvoll, auch Betriebssystemrouti¬ 
nen lassen sich immer noch aufrufen. 
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5.4.2 Ausführen einzelner Routinen im Supervisor- 
Mode 

Wenn man nun nur einzelne Programmteile im Supervisor Mode 
ausführen lassen möchte, kann man das mit dem XBIOS 38 Befehl 
Superexec tun. Allerdings lassen sich in diesem Programmteil dann 
ohne weiteres keine Betriebssystemfunktionen mehr aufrufen. 

Beispiel: 

;Programm, das Routinen im Supervisor-Mode aufruft 
;über XBIOS 38 - Superexec 

;Kapitel5.TOS ASM3.S 

SUPEREXEC EQU 26 ; Funktionsnummer 

XBIOS EQU 14 ; extented basis input output - Xbios Trap 

;***** Aufruf von Superexec ***** 

PEA ROUTINE ;Adresse der auszuführenden 


ADDQ.L #6,SP 


MOVE.W #SUPEREXEC,-(SP) 
TRAP #XBIOS 


;Routine auf den Stack 
;Funktionsnummera.d. Stack 
;XBIOS Betriebssystem 
; Routinen aufrufen 
;Stack zurück 


QUIT ********* siehe oben !! 


CLR.W -(SP) 
TRAP #1 
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;****** Hier folgt aufzurufende Routine ***** 

ROUTINE: ;Label der anzuspringenden Routine 

; Programmcode im Supervisor-Mode 
; Jedoch keine Betriebssystem-Aufrufe !!! 


END 


RTS 


Wird mit einem RTS d.h. 
retum from suproutine beendet 
“springt“ dann hinter den TRAP #XBIOS 
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8.5 Schleifen und Entscheidungsanweisungen 
in Assembler 

Auf der Diskette befinden sich vollständige und lauffähige Program¬ 
me, bei den kommenden Beschreibungen werde ich (auch der 
Übersicht halber) schon erklärte Programmteile einfach weglassen 
und mich auf das "Wichtigste" konzentrieren. 

;***** ähnlich FOR NEXT ***** 

;KAPITEL5.TOS 

;ASM4.s 

MOVE.W #100,DO 
SCHLEIFE: 

; Alles was hier kommt wird 101 mal ausgeführt 

DBRA DO,SCHLEIFE 

;******** qui j ******* übertrage von oben 
END 

Dieses Programm wäre vergleichbar mit dem BASIC Programm 
ForT&=0 to 100 
’Programmteil 
NEXT T& 

;***** ähnlich Repeat Until 

;KAPITEL5.TOS 

;ASM5.S 

REPEAT: ;Label 

; Hier würde jetzt ein Programmteil kommen 

CMP.W #100,DO ; CMP CoMPare - vergleiche 100 mit 
; dem Inhalt von DO 

BNE.S REPEAT ; Branch if Not Equal; verzweige, wenn ungleich 

******* Q[J|"p ********** 

END 

Ist vergleichbar mit 

REPEAT 

’ Hier würde "etwas Programm" kommen 

UNTIL a&<>100 
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Was macht nun der ’CMP’ Befehl ? 

Der ’CMP’ setzt die condition codes im Statusregister ! Je nach 
dem, welche condition codes gesetzt sind, reagiert z.B. der beding¬ 
te Sprungbefehl anders. 

Tabelle - Wirkung des CMP Befehls aus dem Status Byte 


CONDITON CODE 1 

BEDEUTUNG 

1 Status Bvte 

CC 

Carry Clear 

c=o 

CS 

Carry Set 

C=1 

EQ 

EQual 

Z=1 

F 

False 

egal, immer erfüllt 

GE 

Greater or Equal 

N=1, Z=1 

GT 

Greater Than 

N=1 

Hl 

Higher 

C=1 

HS 

Higher or Same 

C=1 oder Z=1 

LE 

Less or Equal 

Z=1 

LO 

LOwer 

alle 0 

LS 

Less or Same 

alle 0 oder Z=1 

LT 

Less Than 

Z=1 

Ml 

Minus 

N=1 

NE 

Not Equal 

Z=0 

PL 

Plus 

N=0; Z=1 

T 

True 

egal, immer erfüllt 

VC 

oVerflow Clear 

V=0 

VS 

oVerflow Set 

V=1 


CMP bildet die Differenz zwischen Ziel und Quelle und setzt je 
nach Ergebnis das Status-Byte z.B. in ’DO’ befindet sich der Wert 
100, dieser wird mittels ’CMP #99,DO’ mit 99 verglichen, dann setzt 
der Prozessor das Negativ Flag, weil 99-100 kleiner als Null ist. 
Das Setzen der Flags im Status Byte erfolgt nicht nur durch die 
Vergleichsoperationen sondern im Prinzip bei allen Prozessorope¬ 
rationen, allerdings sollte man darauf achten, daß jeder Befehl nur 
bestimmte Flags setzen kann. Informationen darüber erhält man 
durch Probieren mit einem guten Debugger oder durch Nachlesen 
in Prozessorbüchern (siehe Literaturverzeichnis). 
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5.6 68030-Spezifisches 

5.6.1 Aus/Einschalten der 68030 Caches 

Eine weit verbreitete "Unart" guter Demo Programmierer ist das 
Schreiben von selbstmodifizierendem Code. Selbstmodifizierend ist 
ein Programm, wenn es sein eigenes Textsegment ändert, d.h. Tei¬ 
le des eigenen Programmtextes mit einem neuen "Programm“ 
überschreibt. Meist sind es nur Conditions oder Konstanten, die im 
bestehenden Programm geändert werden, das geht meist schneller 
als das Verzweigen in andere Routinen. In Situationen, wo der De¬ 
mo/Spieleprogrammierer an die Grenzen der Prozessorleistung 
stößt (wenn wirklich nichts mehr zu optimieren geht) greift er gern 
zu dem Mittel, kleine Änderungen direkt im Programm vom Pro¬ 
gramm selbst vornehmen zu lassen. Auch spart er damit Speicher. 

Nun, auf dem 68000 ist diese Technik meiner Meinung nach vol- 
kommen legitim, denn nur so sind viele der wirklich beeindrucken¬ 
den Demos möglich. Allerdings "sollte" man neue Programme so 
schreiben, daß sie auf allen ATARI-Rechnern laufen! Und daher, 
wenn möglich, den Prozessor testen (siehe Kapitel über die Korn 
patibilität) und zumindest an den kritischen Stellen auf Geräten mit 
Prozessoren > 68020 den Cache ausschalten, besser noch eine al¬ 
ternative Routine bieten, die die Fähigkeiten des jeweiligen Prozes¬ 
sors nutzt. Auch sollte man versuchen, Cache-Beschleuniger-Kar- 
ten oder MEGA STE’s zu berücksichtigen, d.h. den zu modifizie¬ 
renden Teil des Programms nicht weiter als 16 KB von dem zu mo¬ 
difizierenden Teil weg zu plazieren, damit die ganze Sache kom¬ 
plett im Cache stattfindet. 
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Zum Aus/Einschalten der Caches muß 


MOVEC CACR.DO 
ANDI #$FEFE,D0 
MOVEC DO.CACR 


DC.W $4e7a,2 

ORI #$3111 ,D0 zum Einschalten 
DC.W $4e7b,2 


im Supervisor-Mode ausgeführt werden. 

*** Achtung ! *** das Desktop schaltet nach Beendigung eines Pro¬ 
gramms die Caches, je nach Voreinstellung, wieder an oder aus. 
(bei TOS 3.01) 

Der 'MOVEC Befehl ist ab dem 68010 in der Familie der 680X0 
Prozessoren integriert. Er bietet Zugriff auf die neuen Register die¬ 
ser Prozessoren und zwar die SFC (Source Function Code) und 
die DFC (Destination Function Code) ab 68010, diese beiden Regi¬ 
ster sind je 3 Bit breit und setzen drei Pins (die an allen 68000 Pro¬ 
zessoren vorhanden sind), je nach gesetzten oder gelöschten Bits, 
hoch bzw. niederohmig. Damit sind spezielle hardwareorientierte 
Speicherkonzepte möglich (eine Erklärung würde zu weit führen, 
da dies zur Systemprogrammierung gehört). Zudem läßt sich noch 
das VBR (Vector-Basis-Register) durch den ’MOVEC’ verändern, 
was eine Verschiebung der Vektortabelle des Prozessors zu Folge 
hat. Damit ist es z.B. möglich, mehrere alternative Vektortabellen 
gleichzeitig im Speicher zu halten, das wiederum vermeidet lästi¬ 
ges Umkopieren (Systemprogrammierung). Ab dem 68020 kann 
man mit dem 'MOVEC Befehl noch die Register zu Cacheverwal¬ 
tung ’CAAR’ (CAche Address Register) und ’CACR’ (CAche Con¬ 
trol Register) manipulieren. Für uns dürfte allerdings nur das 
’CACR’ Register interessant sein, da man mit ihm den Cache ein- 
und ausschalten kann. Alle anderen Funktionen (außer beim Ein¬ 
schalten gleich den Burst-Mode zu aktivieren) dürften uninteres¬ 
sant sein, da beim 68040 (z.B. im Falcon 40) diese auf andere Re¬ 
gister ausgelagert oder erst gar nicht implementiert (die Kunst liegt 
im weglassen) worden sind. Näheres dazu finden Sie in jedem bes¬ 
seren Prozessorbuch (siehe Literaturverzeichnis). 
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’ANDI’/’ORI’ sind Befehle, die eine logische UND- bzw. ODER- 
Verknüpfung einer Konstante mit einem Ziel ausführen (in unserem 
Fall einem Register). Da beim ’CACR’ Register eine Menge von 
Bits manipuliert werden können, empfiehlt es sich, nur die Bits zu 
setzen bzw. zu löschen, die man wirklich setzen/löschen will, dafür 
sind logische Verknüpfungen bestens geeignet. Direktes Beschrei¬ 
ben dieses Registers ist nicht zu empfehlen, da noch unklar ist, 
welche Wirkungen die reservierten Bits in späteren Prozessor¬ 
versionen haben werden. 


CflCR 68020/30/40 


31 

31 

15 

14 

13 

12 

11 

18 

9 

8 

7 

6 

5 

4 

3 

2 

1 

8 

DE 

* 1 


IE 

1 

UH 

DBE 

CD 

CEO 

FD 

ED 

8 

8 

8 

IBE 

CI 

CEI 

Fl 

El 

010 

i 

1 

040 


OJO 

010 

030 

030 

030 

030 




030 

020/030 

020/030 

020/030 

020/030 


nur 68040 

DE = Enable Data Cache, ein/ausschalten des Daten Caches 
IE = Enable Instruction Cache, ein/ausschalten des Befehls Cache 

nur 68030 

WA = Write Allocate, Cache update ein/ausschalten 

DBE = Data Burst Enable, Füllen des Daten Caches im Burst mode 

CDE = Clear Data Cache, Löschen des Daten Cache 

FD = Freeze Data Cache, Inhalt des Daten Caches einfrieren 

ED = Enable Data Cache, Ein/Ausschalten des Daten Caches 

IBE = Instruction Burst Enable, Füllen des Befehls Cache im Burst mode 

nur 68020/030 

CI = Clear Instruction Cache, Löschen des Befehls Cache 

CLI = Clear Instruction Cache Entry, Löschen eines Eintrags des Befehls Cache 

Fl = Freeze Instruction Cache, Inhalt des Befehls Cache einfrieren 

El = Enable Instruction Cache, Ein/Ausschalten des Befehls Cache 
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5.6.2 Zusätzliche Adressierungsarten ab 68020 

Bei allen Adressierungsarten mit Index, kann hinter das Indexregi¬ 
ster noch einen ’scale factor’ setzen. Mit diesem wird dann das In¬ 
dexregister multipliziert. Diese Erweiterung bietet sich zur Tabel¬ 
lenverarbeitung an. 

Beispiel: 

MOVE.L 100(A0,D0.w*8), 1040 
der ’scale factor’ kann 1,2, 4, 8 betragen 


5.7. Schlußwort zu diesem Kapitel 

Natürlich bin ich mir bewußt, daß man nach dem Lesen dieses Ka¬ 
pitels noch lange kein Assembler kann ! Trotzdem hoffe ich, daß 
ich Ihnen einige wichtige Hinweise zum Verständnis von Assembler 
und somit zum Verständnis der folgenden Kapitel geben konnte. 
Gerade den Umsteigern von anderen Geräten, die schon etwas Er¬ 
fahrung mit dem Assembler ihres Gerätes haben, dürfte ich wohl 
ein ganzes Stück weiter geholfen haben ?! 
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A.6. Wie schaffe ich es jetzt, ein eigenes Spiel 
zu schreiben ? 

Nun, sie haben sicherlich schon konkrete Vorstellungen, was für 
ein Spiel sie schreiben wollen und können es in eine der Kategorien 
einordnen die jetzt folgen. Sie müssen allerdings verstehen, daß ich 
nur Tips zu jedem Genre geben kann, ich hoffe daß sie Ihnen wei¬ 
terhelfen können ! 

6.1 Adventures 

6.1.1 Text Adventures (z.B. Infocom Adventures) 

Das Wichtigste bei Textadventures ist der Parser! Um einen guten 
Parser zu schreiben, sollten sie die Sprache, die der Parser ver¬ 
stehen kann (Deutsch, Englisch, Französisch), gut beherrschen, 
sie sollten die Schlüsselwörter kennen, die eine Sprache ausmacht. 
Außerdem sollten sie wissen, welche Wörter sie ignorieren können! 
Auch sollten sie versuchen, Fehler, die bei der Eingabe entstehen 
können, von vornherein herauszufiltern. 

Ein Beispiel für einen Dialog: 

Spieler: Rede mit König 

Im Computer - In Groß- oder Kleinschrift wandeln. 

(Filtert Fehler bei Groß- oder Kleinschreibung 
heraus) 

REDE MIT KÖNIG 

- Schlüsselwörter suchen 

(Das ist natürlich nur ein sehr einfaches Beispiel) 

REDE KÖNIG 

- Ist diese Funktion in diesem Moment möglich 
d.h. ist der König im Raum etc. ? 
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Der Computer müßte somit in einen ''Gesprächsmodus" schalten 
und dann entsprechende Antworten auf entsprechende Inhalte in 
dem kommenden Dialog geben. 

Entsprechende Befehle zum Realisieren eines solchen Algorithmus 
finden sie bei den Stringfunktionen der jeweiligen Programmier¬ 
sprache. 


6.1.2 Grafik/Text Adventures (z.b. The Pawn, Heiiowoon) 

Diese haben den Vorteil gegenüber reinen Text - Adventures, daß 
man die Räume nicht so genau beschreiben muß, denn der Spieler 
hat ja Augen im Kopf. Es bleibt jedoch das Problem der Bilder, da 
der Spielspaß proportional mit dem Interesse an den Bildern 
wächst. Außerdem sind die Bilder das einzige, was der Käufer bei 
Testberichten in den jeweiligen Zeitungen selbst beurteilen kann ! 

Jetzt noch ein paar technische Tips ! 

Zwischen Text und Grafik (z.B. mit TIMER B) die Auflösung um¬ 
schalten (beim ST zwischen ’niedrigerV’mittlerer’ Auflösung). Man 
hat somit mindestens 16 Farben für das Bild und 80 Zeichen pro 
Zeile für den Text. Man sollte beim Umschalten den Timer B immer 
ein paar Zeilen vor dem Beginn des Textes auslösen lassen und 
entsprechend Platz zwischen Grafik und Text lassen, da sich der 
Timer B Interrupt (wenn man nicht fast alle anderen Interrupts 
sperrt oder auf speziell modifizierte, eigene Routinen richtet) um 
einige Zeilen verschiebt - siehe Farbumschaltung im beigefügten 
Spiel (Kapitel 4). 

Diese Umschaltung bringt jedoch auch Kompatibilitätsprobleme mit 
sich, da die Rechner der nächsten Generation diese oder jene Gra¬ 
fikauflösung vielleicht gar nicht mehr besitzen, auch verbaut man 
sich damit die Möglichkeit der Ausgabe auf entsprechende Grafik¬ 
karten, die für diese Art von Spielen besonders gut geeignet sind. 
(Siehe auch dazu Kapitel 8 über die Kompatibilität) 
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6.1.3 Animierte Grafik Adventures (z.B. Maupitti Island) 

Die Grafik muß bei diesen Programmen genauso gut (oder besser) 
wie die der nur Grafik-Adventures sein. Dafür fällt in den meisten 
Fällen der Parser weg. Die Programme werden über Pulldown - 
Pop up Menüs, und/oder Tastenkürzel oder Befehlszeilen am unte¬ 
ren Rand gesteuert. In den meisten Fällen kann man Gegenstände 
auf dem Bildschirm mit der Maus anklicken und dann angeben, was 
man mit ihnen anfangen möchte. Auch diese Art von Programmen 
läßt sich so programmieren, das sie auf allen Atari-Rechnern mit 
allen Grafikkarten laufen. 


6.1.4 Actionadventures (z.B. Larry, Monkey Island u.v.m) 

Tja, die sind gar nicht so leicht zu schreiben. Das Hauptproblem ist 
das Erzeugen von mehren Ebenen, die immer ein Stückchen weiter 
im Hintergrund liegen. Das kann man z.B. durch das Erzeugen von 
mehreren Masken realisieren, wobei man immer mehr vom Hinter¬ 
grund beim Spielersprite ausmaskiert (mit einer Maske vom Hin¬ 
tergrund verknüpft). Das ist nicht so speicherintensiv, da jede 
Maske nur aus einer Bitplane besteht, wie das Kopieren der jeweili¬ 
gen Ausschnitte der jeweiligen Ebenen, denn dazu müßte man alle 
Ebenen in der Tiefe (z.B. eine Palme im Vordergrund) mit allen Bit¬ 
planes im Speicher bzw. auf der Diskette haben. Das Konstruieren 
eines Interpreters, wie der von Sierra, ist in etwa fast so schwer 
wie eine komplett neue Programmiersprache zu entwickeln, doch 
wenn man einen solchen Interpreter erst mal hat, kann man jede 
Menge Spiele entwickeln. 
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6.2. Action Spiele 

6.2.1 Ballerspiele (z.B. Wings of death, Xenon II ...) 

Sie sind eigentlich öde, deshalb müssen Elemente her, die diese 
Art von Spielen interessant machen. Ausgeklügelte Extra Waffen, 
Bonus - Spiele Extra Leben u.v.m. ! Aber das ist nicht alles, gute 
Grafik, fließende Bewegungen etc. etc. sind ein Muß. 

Das ist für den ungeübten Programmierer kaum zu bewältigen. Wie 
man sieht (Argon 4), kann ein weniger aufwendig gestaltetes Pro¬ 
gramm großen Spaß bereiten. 

Wenn Sie es nicht einmal schaffen, eine komplette Demo mit 
Scrolltext, hüpfenden Sprites, digitalem Sound, scrollendem Screen 
und vielen Rasterinterrupts zu schaffen, also eine richtig gute De¬ 
mo, sollten Sie nicht versuchen, ein professionelles Ballerspiel zu 
schreiben (sie werden es nicht los !!! außer sie haben eine geniale 
Idee). Aber gute PD- oder Shareware-Programme sind ja auch 
nicht zu verachten und man macht vielleicht irgend jemanden eine 
(zumindest für eine gewisse Zeit) kleine Freude damit. 


6.2.2 Ballerspiele mit Vektorgrafiken (z.B. Starglider) 

Dazu benötigt man gute Kenntnisse in Vektoralgebra und gute Al¬ 
gorithmen zum Zeichnen von Linien. Natürlich kann man auch die 
Funktionen zum Zeichnen von Linien des Betriebssystems (VDI) 
benutzen. Da diese aber relativ langsam sind, dürfte das erst ab 
Atari TT oder Falcon030 sinnvoll sein (eine gute Beschleunigerkar¬ 
te oder eine Grafikkarte mit speziellem Grafikprozessor reicht auch 
schon). Leider würde eine solche Einführung (ich hasse diesen 
Satz) den Umfang dieses Buches sprengen, weiterführende Litera¬ 
turfinden Sie im Literaturverzeichnis,siehe Anhang B. 
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6.2.3 Action - Strategiespiel (z.B. Archon l+ll,Lemmings) 

Bei dieser Art von Spielen ist meist die Idee entscheidend, viele 
gute Ideen lassen sich schon relativ einfach realisieren. Es ent¬ 
scheidet eben der Spielwitz und die Suchtgefahr eines Spieles. Am 
interessantesten für den Spieler ist meistens der Zwei-Spieler-Mo- 
dus, denn kein Programm kann so interessant sein, wie ein zweiter 
Spieler, und das wird auch noch einige Jahre so bleiben. 


6.3 Simulationen 

6.3.1 Handels-/Wirtschafts-/Welten-/Städtesimulation 

(z.B. Sim City, Populus, Oil Imperium, Rings of Medusa) 

Diese Programme lassen sich meist komplett in einer Hochsprache 
schreiben, es gibt natürlich auch Ausnahmen wie Populus. Ich ken¬ 
ne z.B. den Programmierer von Oil Imperium recht gut (Hallo Si¬ 
mon, ich hoffe, Du hast nichts dagegen, daß ich dich hier erwäh¬ 
ne), daher weiß ich, daß Oil Imperium auf dem ST fast komplett in 
GFA - Basic 3.0 geschrieben worden ist und nur einige wenige As¬ 
sembler - Routinen als Inlines hinzugefügt worden sind. Beim Pro¬ 
grammieren von Simulationen sollte man darauf achten, daß Spiel¬ 
witz und Nähe zur Realität sich die Waage halten, und daß das 
Programm auch ohne Genuß einer mehrere hundert Seiten starke 
Anleitung spielbar ist, denn wer liest sie schon bevor er spielt? 
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Worte zum Ende des Kapitels: 

Ähnlich wie beim "Wort zum Sonntag", noch ein paar Worte zum 
Ende des Kapitels. 

Der Übergang von einer Art von Spielen zu einer anderen ist flie¬ 
ßend und wer verzweifelt nach Informationen über z.B. Sportspiele 
in diesem Kapitel sucht, findet sie versteckt in all den anderen be¬ 
sprochenen Genres. Das Programmieren ist eine Tätigkeit wie das 
Modellbauen, man sollte schon wissen, was im Endeffekt dabei 
herauskommen soll. Es ist aber auch - gerade bei der Spielepro¬ 
grammierung - ein kreativer Prozeß, so wie das Malen oder das 
Komponieren. Trotzdem ist es wichtig, sich zu jedem Schritt Noti¬ 
zen zu machen, Programme im Programmtext zu dokumentieren. 
Sie müssen nicht unbedingt Flußdiagramme und Ablaufpläne etc. 
zeichnen! Aber modulare Programmierung, d.h. Zerlegen eines 
Problems in lauter kleine Teilstücke (z.B. Proceduren) die man mit 
Extremwerten (Minimas und Maximas) testen kann, sollten sie 
schon praktizieren. Wenn man dann zu jedem Modul schreibt, was 
es eigentlich macht, können Sie Ihre Programme mit wachsendem 
Kenntnisstand immer weiter verbessern und vielleicht auch irgend¬ 
wann einmal Ihr erstes Programm veröffentlichen !!! 
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7. Techniken der Demoprogrammierung 

Eine der wichtigsten Regeln beim Anschauen von Demos ist: Es ist 
nichts so schwer, wie es aussieht! 

Viele "Screens" (Teile einer Demo) sind, so toll sie auch aussehen 
mögen, weniger eine programmiererische Glanzleistung als eine 
Frage des Gewußt-Wie. Um das zu erkennen, muß man ein biß¬ 
chen was über die Grenzen der ST/STE/TT/Falcon Hardware wis¬ 
sen. Einige Grenzen möchte ich hier aufzeigen und mit welchen 
Tricks man sie beseitigen kann. 


7.1 Die Grenzen der Hardware 

7.1.2 Der Sound 

Beim Falcon030 müssen diese Grenzen sicherlich noch gesteckt 
werden. Wozu der DSP bei geschickter Programmierung in der La¬ 
ge ist, ist noch relativ unklar; unglaubliche Soundeffekte warten 
darauf, durch geschickte Programmierung in 16 Bit Stereo zu Ge¬ 
hör gebracht zu werden. 

Der DMA Soundchip des STE/TT ist schon eher eine bekannte 
Größe, der zwar von der Hardware nur den einen Speicherbereich 
8 Bit Stereo abspielen kann (also ein Stereo DMA Kanal) und via 
Microwire Interface Höhen und Bässe des abgespielten 2 Kanal 
Sounds einstellen kann. Das ist im Vergleich zum Paula, der im 
AMIGA eingebaut ist, nicht gerade überzeugend, jedoch muß man 
bedenken, daß der DMA Kanal im STE/TT fast keine Prozessorzeit 
schluckt, da er die Daten genau wie der Video-Shifter dann holt, 
wenn der Prozessor nicht auf den Speicher zugreift. Das ist das 
starre Bus-Timing in ST/STE/TT; die CPU muß nur in den selten¬ 
sten Fällen warten, so daß der CPU durch Zugriffe des VIDEO- 
und (bei STE/TT) AUDIO-Shifters auf den Bus nur etwa 10% sei¬ 
ner Performance "flöten" gehen. Der AMIGA verliert je nach Auflö¬ 
sung und Abspielfrequenz der gespielten Sounds, Blitter, Copper 
Einsatz schätzungsweise 70% der CPU Performance im CHIP - 
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RAM. Da also die ATARI User noch ein bißchen Prozessor-Zeit 
zur Verfügung haben, verschwenden wir sie einfach mit der Emula¬ 
tion des vierstimmigen Sounds (wie, siehe Kapitel B.4). Das klingt 
dann auch schon recht brauchbar. 

Die Grenzen des YAMAHA- oder baugleichem General Instru¬ 
ments-Soundchips liegen noch ein paar Level tiefer. Eigentlich kann 
dieses Ding nur rechteckige Wellenformen und Rauschen erzeu¬ 
gen. Da konnte der Chip im ATARI 400/800/600XL - 1200XL/130XE 
etc. noch besseren Sound von sich geben, denn der hatte wenig¬ 
stens Filter und war vierstimmig (!). Aber selbst im Vergleich zum 
müden C64 Sounderzeuger kann dieser LOW LEVEL I/O Chip, den 
man in den ST’s findet, mit seinen geringen Soundfähigkeiten 
nicht mithalten. Wie man trotzdem digitalen Sound aus diesem Ding 
herauskitzelt, findet man in Kapitel B.4. Im Kapitel A.4 habe ich ja 
schon gezeigt, wie man selbst in Basic mit viel Rechteck und Rau¬ 
schen Musik machen kann. 


7.1.2 Die Grafik 

Wohl aus technischen Gründen liegen die Bitplanes im Grafikspei¬ 
cher für je sechzehn Pixel hintereinander (außer "True Color" beim 
Falcon030). So muß man beim Bearbeiten eines Bildpunktes in ei¬ 
nem 256 Farbmodus acht Wörter des Bildschirmspeichers manipu¬ 
lieren. Bei einer VGA - Karte oder beim Archimedes reicht für die¬ 
selbe Aufgabe der Zugriff auf ein einziges Byte. Die Organisation 
des ATARI Bildspeichers ergibt besonders beim horizontalen 
Scrollen Probleme, da ja der Abstand zwischen dem Wort in dem 
die einen 16 Pixel für eine Plane und den nächsten 16 Pixel für die 
gleiche Plane Anzahl der Planes mal einem Wort ist. Das dauernde 
Arbeiten mit diesen Offsets (Abständen) ist sehr knifflig und kostet 
relativ viel Rechenzeit. Zudem ist noch zu bemerken, daß die 
ATARI’s zwar ergonomische Bildwiederholfrequenzen (60 Hz in 
Farbe und 71 Hz in Monochrom) zulassen, aber die Menge der 
Farben bei ST/STE mit 16 aus 512 bzw. 4096 beim STE sein Maxi¬ 
mum erreicht hat, beim Uramiga normal 32 aus 4096 und HAM vol- 
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le 4096. Ach ja, da wir gerade dabei sind, der HAM Modus (das ist 
vielleicht auch für ein paar ST-User interessant) funktioniert in et¬ 
wa so: 


HAM MODUS: (amiga) 

6 Bitplanes für einen Bildpunkt, 

die Bits 6 & 7 eines Bildpunkts legen fest: 

a) Rot, Grün oder Blauteil des letzten Bildpunkts modifizieren 

Bit 6 & 7 01 = blau modifizieren 

10= rot modifizieren 
11 = grün modifizieren 

b) die Farbe eines Farbregisters als Bildpunkt 

Bit 6 & 7 00 = Farbwert aus einem von 16 Palettenregister 

die restlichen vier Bits eines Bildpunkts legen fest: 

a) den Wert von der Rot-, Grün oder Blaumodifizierung 

b) welches Farbregister dem Bildpunkt zugeordnet wird 
Aber jetzt weiter mit meinen geliebten ATARI Rechnern ! 
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7.2. Ein paar Tricks um die Hardware zu überlisten 

Wie man mehr als sechzehn Farben auf einen Bildschirm darstellt, 
erfährt man in Kapitel B.3; auch habe ich das ja schon im letzten 
Kapitel angerissen. Der Sound wird, wie schon erwähnt, in Kapitel 
B.4 ausführlich abgehandelt, also bleibt uns nur noch das Problem 
mit dem Fine - Scrolling. 


7.2.1 Schnelles Scrolling auf den ATARI Rechnern 

Information Hardwarescrolling der STE Serie und die Syncscroller 
sind in Kapitel B.1 nachzulesen. Ich beschränke mich in diesem 
Kapitel mit der Erklärung von Tricks, die das Scrolling auf den Ur - 
ST’s beschleunigen. 


7.2.2.1 Vertikales Scrolling 

Bei dem Übertragen von vollen vier Planes gibt es nur eine wirklich 
sinnvolle Lösung, das Kopieren von Speicher, so wie ich das bei 
Argon 4 mit dem ’BMOVE’ aus GFA - Basic gemacht habe. Dieser 
’BMOVE' kann sogar überlappende Speicherbereiche kopieren, das 
ist bei einer eigenen Routine natürlich nicht nötig. Auf der folgenden 
Seite finden Sie eine Beispielroutine in Assembler: 
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Hier eine solche Kopierroutine in Assembler! 

******** Kopieren von n Zeilen eines Lores - Screens ****’ 

* In AO befindet sich die Anfangsadresse Quelle 

* In AI die Anfangsadresse Ziel 

* DO Zähler für die zu übertragenden Zeilen 

**************** Kopieren von n Zeilen ************** 


zeile: 


*************** ©ine Zeile **************** 


movem.l (A0)+,D1-D7/A2-A6 
movem.l D1-D7/A2-A6,(A1) 
lea 48(A1),A1 
movem.l (A0)+,D1-D7/A2-A6 
movem.l D1-D7/A2-A6,(A1) 
lea 48(A1),A1 
movem.l (A0)+,D1-D7/A2-A6 
movem.l D1-D7/A2-A6,(A1) 
lea 48(A1),A1 
movem.l (A0)+,D1-D4 
movem.l D1-D4,(A1) 
lea 16(A1),A1 


; 12 Longs lesen (Quelle) 

; schreiben (Ziel) 

; Addiert 52 Bytes zu AI dazu 
; nochmal 13 Longs lesen (Quelle) 
; schreiben (Ziel) 

; nochmal 13 Longs lesen (Quelle) 
; schreiben (Ziel) 

; die letzten 16 Bytes 


******************************************* 


dbra DO,zeile 

***************************************************** 


END 
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Nun, was macht das Programm ? 

Es kopiert die Menge von Zeilen+1, die in ’DO’ stehen von ’AO’ nach 
’AI’, ich benutze hierbei ein ’movem’ weil dieser bei der Übertra¬ 
gung von mehr als 3 Register in den Speicher schneller ist als ein 
’move’. Ich gehe bei der Programmierung von einem 320*200 - 16 
Farb-Bild aus; bei größerem oder kleinerem Speicherbedarf für ei¬ 
ne Zeile kann die Routine entsprechend abgeändert werden. 

Der Unterschied zwischen einem ST und STE im Bezug auf verti¬ 
kales Scrolling ist das fehlende LOW - Byte der ST - Serie bei den 
Video-Basisregistern. Dieses LOW - Byte ermöglicht es dem STE, 
den Bildschirmspeicher wortweise zu verschieben (siehe dazu 
auch B.l.2.2.1). Trotz alledem läßt sich der Bildschirmspeicher 
acht zeilenweise verschieben. Denn der Bildschirmspeicher muß 
duch das fehlende ’LOW - Byte’ auf einer 256 Bytes Grenze liegen. 

Beispiel: 

Adresse: 

200000 DEZIMAL 
$030D40 HEXADEZIMAL 


HIGH 

MID 

LOW 


3 

13 

64 

DEZIMAL 

$03 

$0D 

$40 

SEDEZIMAL bzw. HEXADEZIMAL 


diese Adresse würden STE/Falcon/TT ohne weiteres in ihre Video¬ 
register übernehmen (z.B. via setscreen bzw. XBIOS(5)) der ST 
allerdings würde nur 

HIGH MID 
$03 $0D 

übernehmen, was wiederum die Adresse $030D00 ergibt, also 
Adresse 199936, die sich glatt durch 256 teilen läßt. Nun ist eine 
Lores - Zeile 160 Bytes lang und acht Zeilen 1280 Bytes, dies ist 
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das kleinste, gemeinsame Vielfache von 256 und 160, da 5*256 
ebenso 1280 ergibt, somit ist auf jedem normalen ST ein Hardwa¬ 
remäßiges acht Zeilen vertikales Scrolling möglich. Wenn man nun 
den Bildschirmspeicher sehr schnell scrollen möchte, ist eine Zeile 
pro VBL eh ein bißchen wenig und acht Zeilen in manchen Fällen 
gerade noch erträglich und ohne größeres Kopieren von Speicher 
zu realisieren. 


7.2.2.2 Horizontales Scrolling 

Auf einem normalen ST mit 8 MHZ CPU und ohne Blitter ist es auf 
normalem Wege (Bitverschieben) unmöglich, horizontales Finesc¬ 
rolling (bei jedem Bildaufbau eine Spalte) über den ganzen Bild¬ 
schirm und vier Planes zu realisieren. Man schafft allerhöchstens 
1/3 des Bildschirms. Das liegt an der, wie schon erwähnt, ineinan¬ 
der verschachtelten Struktur der Bitplanes im Bildschirmspeicher. 

Scrolling durch Bitverschieben: 


16 Fa r ben 


ersten 16 PiMe I 


l.uort | 1 1 1 1 1 1 1 1 1 1 I 1 1 1 I l| 
2 . uor t |iimiinnmi i] 
3-Uort | I 1 1 1 1 1 I I 1 1 1 I 1 1 I 1~| 
•» Uor ( | 1 I 1 1 1 1 1 1 1 1 1 I 1 1 1 1~1 


16 PI MC I 


5. Uort [i 1 I 1 I 1 1 1 1 1 1 I I 1 I l| 

6 . Uort [j I 1 1 l 1 1 I l 1 1 1 I I l t] 

7. Uor« fi lillllllllliii i] 

O.Uort fl 1 l 1 1 1 1 1 1 I l I t I 1 r| 


_ l 

etc. 


Schemtische Darstellung des horizontalen Scrolling via Bitver¬ 
schieben: 

Beispielroutine dazu auf Diskette ! 

Aber wie gesagt, das ist keineswegs schnell genug für Spiele ! Für 
Spiele empfiehlt sich eine andere Methode, "da der Spieler sonst 
beim Spielen einschläft". 
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Wenn man den zu bewegenden Screen 16 mal verschoben im 
Speicher hält (16*32k (Bildschimspeicher ST - lores) = 256k), also 
alle Pixel schon mal irgendwo verschoben liegen, muß man zum 
größten Teil dann nur Wörter bzw. Langwörter in den Bildschirm¬ 
speicher kopieren und das schafft sogar ein ganz normaler 68000er 
8MHz alle 20ms (50Hz). Die oben angestellte Rechnung mit einem 
benötigten Speicherbedarf von 256k zeigt schon den Nachteil die¬ 
ser Methode an. Für den Falcon (640*480*256 Farben) würde dies 
z.B. bedeuten, über 4MB Zwischenspeicher zum Scrollen zu be¬ 
nutzen (wie gut, daß das Ding einen schnellen Blitter hat), "aber 
was tut man nicht alles für ein softes Scrolling". Viel Speicher kann 
man sich bei dieser Technik sparen, wenn der zu scrollende Hin¬ 
tergrund aus Mustern besteht, die z.B. nach dem vierten Verschie¬ 
ben genauso wie am Anfang aussehen oder wenn nur bestimmte 
Teile des Bildschirms scrollen, z.B. nur die untere Hälfte und im 
oberen Teil des Bildschirms ein blauer Himmel mit Sonne und An¬ 
zeige für Punkte und Spieler etc. stillsteht. 

Mit der oben beschriebenen Technik kann man natürlich nicht nur 
scrollen, ein im Speicher 16 mal (um ein Pixel) verschobenes Spri¬ 
te kann man nicht nur Zeile für Zeile aus einem der 16 Pufferspei¬ 
cher kopieren sondern auch Zeile für Zeile aus unterschiedlichen 
Puffern, um somit Effekte wie "wellige" Sprites (bekannt aus eini¬ 
gen UNION - Demos) zu erzeugen. 


7.2.3. Vergrößern von bitmapped Graphics 

Bitmapped bedeutet pixelorientiert, das Gegenstück ist Vektorgra¬ 
fik. Die Techniken, die ich hier kurz vorstellen möchte, kann man 
verwenden, um eine schnelle Lupe für ein Grafikprogramm zu ent¬ 
werfen oder auch um Sprites wie bei Wing Commander zu vergrö¬ 
ßern oder zu verkleinern. 
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7.2.3.1 Vertikales Vergrößern (in Y - Richtung) 

Fangen wir mal mit dem Einfachsten an, das Verdoppeln stellt im¬ 
mer noch die leichteste Disziplin dar. Dazu kopiert man das zu 
verdoppelnde Objekt Zeile für Zeile in den Zielspeicher, wobei man 
jede Zeile im Zielspeicher doppelt kopiert. 

Man kann allerdings die ganze Sache noch ein wenig flexibler ge¬ 
stalten, wenn man in einem Register einen Zähler einrichtet, der 
angibt, wievielmal die jeweilige Quell-Zeile ins Ziel kopiert wird, 
z.B. 2*.3*,4*. 

Hier eine einfache Veränderung des Listings von 7.2.2.1; dieses 
Listing läßt jetzt schon Vergrößerungen u. andere Effekte zu. Es 
läßt sich auch zum Zusammenkopieren der Planes zweier Bild¬ 
schirme benutzen (erste Zeile - erster Screen, zweite Zeile - zwei¬ 
ter Screen) und somit zum Aufbau des virtuellen Bildschirms zum 
"Hardwarescrollen" von STE/Falcon. 

**** Kopieren von n Zeilen eines Lores - Screens ************* 

;erweitert durch Offset zur nächsten Zeile 
;ermöglicht Vergrößerungseffekte u. Spiegelungen 

* In AO befindet sich die Anfangsadresse Quelle 

* In AI die Anfangsadresse Ziel 

* DO Zähler für die zu übertragenden Zeilen 

* Dl Offset zur nächsten Zeile für Source 

* D2 Offset zur nächsten Zeile für Destination 


Kopieren einer Zeile ************** 


zeile: 


movem.l (A0)+,D3-D7/A2-A6 
movem.l D3-D7/A2-A6,(A1) 
lea 40(A1),A1 
movem.l (A0)+,D3-D7/A2-A6 
movem.l D3-D7/A2-A6,(A1) 
lea 40(A1),A1 


; die ersten 11 Longs lesen (Quelle) 
; schreiben (Ziel) 

; Addiert 44 Bytes zu AI dazu 
; nochmal 11 Longs lesen (Quelle) 

; schreiben (Ziel) 
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movem.l (A0)+,D3-D7/A2-A6 ; nochmal 11 longs lesen (Quelle) 

movem.l D3-D7/A2-A6,(A1) ; schreiben (Ziel) 

lea 40(A1),A1 

movem.l (aO)+,D3-d7/a2-a6 ; die Letzen 40 Bytes 

movem.l d3-d7/a2-a6,(a1) 
lea 40(A1),A1 

***addition des Offsets (Abstand) zu nächsten Zeile ********* 

adda.l D1,A0 ;addiert Offset Source 

adda.l D2,A1 ;addiert Offset Destin. 


************************************************************** 


dbra DO,zeile 


************************************************************** 


END 

Da aber einfache Vergrößerungen z.B *2,*3,*4,*5 für die meisten 
Zwecke nicht fein genug abgestuft sind, es in Maschinensprache 
auf einem 68k bis 68030 ohne FPU keine Floating Point Arithmetik 
gibt, muß man sich mit einem kleinen Trick helfen, um Vergrößer¬ 
ungen wie z.B 2.5 oder 3.12 zu erzeugen. 

Zuerst zur Theorie; benutzt man nicht ganzzahlige Faktoren bei der 
Vergrößerung von Bildern wird nicht Zeile für Zeile gleichmäßig 
vergrößert (wiederholt kopiert) sondern jede Zeile unterschiedlich 
häufig von der Quelle zum Ziel kopiert. 

Z.B.: Faktor 2.5 

Zeile 1: 2 mal 
Zeile 2: 3 mal 

bei noch "krummeren" Faktoren z.B. 2.125 kann es sein, daß man 
kaum noch ein Muster bei den Vergrößerungen pro Zeile erkennt. 
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Hier ein Routine, die dieses Problem löst. 

******** Kopieren von n Zeilen eines Lores - Screens ************* 

* In AO befindet sich die Anfangsadresse Quelle 

* In AI die Anfangsadresse Ziel 

* In A2 Endadresse des Ziels (für clipping) 

* DO Zähler für die zu übertragenden Zeilen 

* Dl > 65535 = Vergrößerung, Dl < 65535 Verkleinerung 

**************** Kopieren einer (Quell) Zeile ************** 


zeile: 


swap 

Dl 

wie_oft: 


cmp.w 

#0,D1 

beq.s 

aus 

cmpa.l 

A2.A1 

bge.s 

out 


movem.l 0(A0),D3-D7/A3-A6 
movem.l D3-D7/A3-A6,0(A1) 
movem.l 36(A0),D3-D7/A3-A6 
movem.l D3-D7/A3-A6,36(A1) 
movem.l 72(A0),D3-D7/A3-A6 
movem.l D3-D7/A3-A6,72(A1) 
movem.l 108(A0),D3-D7/A3-A6 
movem.l D3-D7/A3-A6,108(A1) 
movem.l 144(A0),D3-D6 
movem.l D3-D6,144(A1) 
lea 160(A1),A1 
dbeq 


; alles was >65535 ins 
; niederwertige Wort 

; keine ganze Zeile ? 

; dann raus 

; vergleiche jetzige mit Endadresse 
; >= dann raus (sonst 2 Bomben) 

die ersten 9 Longs lesen (Quelle) 
schreiben (Ziel) 
nochmal 9 Longs der Zeile 
schreiben (Ziel) 
nochmal 9 Longs der Zeile 
schreiben (Ziel) 
nochmal 9 Longs 
schreiben Ziel 
die letzten 4 Longs 
schreiben Ziel 
nächste Zeile des Ziels 
solange Zeilen 


D1,wie_oft 

************************************************************** 


aus: 


sub.w 

Dl,Dl 

; Dl ist dann -1 also löschen 

swap 

Dl 

; niederwertiges wieder nach oben 

add.l 

D2,D1 

; Faktor dazuzählen 

lea 

160(A0),A0 

; nächste Zeile Quelle 

dbra 

DO,zeile 

; solange Zeilen>=0 


out: 

***************************************************** 


END 
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Der Unterschied zwischen dieser und der Kopierroutine vo 7.2.2.1 
ist gar nicht so groß. Zum einen erkennt man natürlich, daß die 
Adresse für Ziel in ’AI’ erst nach dem Kopieren der kompletten 
Zeile auf die Anfangsadresse der nächsten Zeile gesetzt wird zum 
anderen, daß die Quelladress erst nach n - maligem Kopieren (wo¬ 
bei n im höherwertigen Wort von ’DI’ steht) auf die nächste Zeile 
gesetzt. Wenn das höherwertige Wort ’DI’ Null enthält, wird gar 
keine Zeile kopiert. 

Warum im höherwertigen Wort ? 

HW=Höherwertig 
NW=Niederwertig 
in D2 steht z.B. $1A000 

HW NW 

Dl $ 0000 0000 

D1=D1+ $ 1 A000 

Tausche HW mit NW (in Assembler SWAP Dl) 

dann steht in Dl 

$ A000 0001 

da ich beim Vergleichen ’cmp.wc-’ nur das Register oder die Kon¬ 
stante mit dem niederwertigem Wort von ’DI’ vergleiche und der 
Befehl ’dbcc’ auch nur das niederwertige Wort von ’DI’ herunter¬ 
zählt, beibt dessen höherwertiger Teil unangetastet. Ich “swappe“ 
dann wieder die Worte von ’DI’ und addiere wiederum die in ’D2’ 
stehende Konstante zu ’DI’ 

clr.w Dl — > Dl = SA000 0000 

swap Dl — > Dl = $0000 A000 

add.l D2,D1- > Dl = $0002 4000 

d.h die nächte Zeile wird nicht einmal sondern zweimal kopiert. 

Zum Thema Sounderzeugung (B.4.2.2) erkläre ich diese Technik 
nochmals auf eine andere Art, vielleicht wird es dann etwas klarer. 
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7 . 3 . 2.2 Vergrößern in X - Richtung 

Wie man im letzten Abschnitt gesehen hat, ist das Vergößern in Y 
-Richtung recht leicht, das es in X-richtung nicht ganz so einfach 
ist, liegt wieder an der Anordnung der Bitplanes. Trotzdem ist es 
möglich, mit relativ geringem Aufwand mit annehmbarer Geschwin¬ 
digkeit zu vergrößern. Der Trick ist dabei eine Tabelle, die aus ei¬ 
nem Byte ein Wort macht und somit eine Verdopplung der Pixel in 
X - Richtung verursacht. 

Die ersten Elemente einer solchen Tabelle können dann in etwa so 
aussehen: 

2.Element 3.Element 256 Element 

.%0000000000000011, %0000000000001111,. %1111111111111111 

Ist also das erste Byte einer Bitplane eine %0000001, multiplziert 
man den Wert mit 2 (um ein Bit nach links schieben) und holt dann 
das entsprechende Wort aus der Tabelle in dem Fall also ein Wort, 
das so %0000000000000011 aussieht. Das macht man dann für al¬ 
le Bitplanes des entsprechenden Bereichs. Wenn man dann Ver¬ 
größerungen wie mal 4 oder mal 8 vornehmen möchte, kann man 
dann die entsprechende Prozedure des Heraussuchens aus der 
Tabelle mehrmals durchführen, um allerdings Sprites oder änhl. um 
krummere Werte als mal 4; mal 8 wie z.B mal 3 oder gar mal 2.5 
zu vergrößern, müßte man mehrere Tabellen und ein etwas kom¬ 
plexeres Verfahren verwenden. 
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7.4 Diverse kleinere Effekte 

7.4.1 Spiegelungen der Bitplanes an der X - Achse 

Bestes Beispiel für so einen Effekt ist das Spiel ’NEBULUS’ oder 
das Anfangsbild von ’Turrican 2’; aber auch in Demos kann man oft 
gespiegelte Scroller (scrollende Schrift) und ähnliches sehen. Im 
Prinzip ist das kein Problem, man kopiert Zeile für Zeile aber zählt 
die Zieladresse nicht nach oben sondern fängt am Ende des Ziel¬ 
speichers an und erniedrigt die Zeiladresse der nächsten Zeile statt 
sie zu erhöhen. Natürlich liegen Quelle und Ziel meist beide im 
sichtbaren Bereich (Quelle z.B. im oberen und Ziel im unteren). So 
kann man z.B. im oberen Bereich des Bildschirms viele Sprites 
etc. anzeigen und dann die genze Sache komplett nach unten ko¬ 
pieren und dabei spiegeln, was denn wesentlich weniger Rechen¬ 
zeit als ein Neuaufbau benötigt (selbst wenn man die Sprites alle 
schon gedreht im Speicher hätte). 


7.4.2 Schatten 

Wenn man z.B. in LORES (320*200, 16 Farben) die ersten 8 Farb- 
register ausgewählt hat und dann die nächsten acht Register mit 
der Farben in der halben Helligkeit gewählt hat, kann man durch 
’OR’ Verknüpfung mit der Farbe 8 bzw. VDI Farbe 9 einen Art 
Schatten erzeugen. 

Beispiel: 

1.Plane 2.Plane 3.Plane 4.Plane 

%ioomooioioioio %ionooimooooii %iniiiiioooooooo %oooooooooooooooo 

OR 

%oooooooooooooooo %oooooooooooooooo %oooooooooooooooo %iiiiniimuiii 
%ioomooioioioio %ioiiooimoooon %immioooooooo %iiniiiiiiiiiin 

Dieses Beispiel zeigt, wie so ein Effeckt bei der Verknüpfung der 
ersten 16 Pixel mit der entsprechenden Bitkombination von 
Farbe 8 bzw. VDI Farbe 9. 
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7.4.3 Sternenfelder 

Dieser Effekt aller Star Raiders ist relativ leicht zu erzeugen. Man 
wählt per Zufall die Flugrichtung und Geschwindigkeit für einen 
Stern aus und läßt ihn vom Mittelpunkt zum Rand des Bildschirms 
bewegen. Wenn man das mit genügend vielen Sternen macht, ist 
der Eindruck perfekt. Zusätzlich kann man auch Sterne mit größe¬ 
rer Geschwindigkeit von vornherein weiter nach außen plazieren, 
was die Wirkung noch etwas verbessert. Listing dazu befindet sich 
auf der Diskette zu Buch in ’KAPA7.TOS’. 
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A.8. Wie bleibe ich kompatibel 

(zu allen jetzigen und kommenden Ataris) 

Vorwort 

Wer sich einen TT oder Falcon030 gekauft hat, wird feststellen, 
daß man nicht alles auf Anhieb zum Laufen bringen kann. Gerade 
bei Spielen und Demos scheint es Brauch zu sein, den Geräten das 
Programm auf den Leib zu schneidern und das so eng, daß es auf 
einem geringfügig modifizierten Gerät (TOS an anderer Position 
oder 16 MHz Speeder) einfach nicht mehr "zum Laufen zu bringen“ 
ist. Ein Programmierer, der darauf stolz ist, daß er ein Programm 
trotz einer "zu schwachen" Hardware "zum Laufen" gebracht hat, 
darf erst dann auf sich stolz sein, wenn er das Programm so ge¬ 
schrieben hat, daß es auf jeder möglichen Konfiguration und nach 
den Richtlinien des Herstellers (auch wenn’s manchmal schwer 
fällt) programmiert hat. Man kann sich nicht damit herausreden 
(wie die Programmierer auf dem Amiga das bis vor kurzem noch 
mit Recht konnten), daß es keine Richtlinien gäbe und keine Zei¬ 
tung über diese berichtet hätte. Es sind mehr als ein Dutzend Be¬ 
richte über saubere Programmierung unter TOS in den unter¬ 
schiedlichsten Fachzeitschriften erschienen. Also haltet euch dar¬ 
an! 


8.1. Die Hardware 

8.1.1 Schreibe nie hinter den Bildschirmspeicher 

(denn der Atari könnte drei Bomben "werfen") 

Die normale MMU des Atari ST(E) kann nicht mehr als 4 MB RAM 
adressieren, große Teile hinter diesem normalerweise (es geht mit 
etwas Hardware doch) nicht zu adressierenden Speichers sind 
durch die MMU gesperrt ! Das bedeutet wiederum, daß bei einem 
Versuch diesen Speicherbereich zu lesen oder zu beschreiben, die 
CPU von der MMU (Memory Management Unit - "Speicherverwal- 
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ter") einen Addressfehler gemeldet bekommt, weil sie diese Ad- 
dresse ja gar "nicht kennt", was wiederum einen Programm - Ab¬ 
sturz zur Folge hat. 

Lösung: 

1) Nie über den Bildschirmspeicher hinweg lesen oder schreiben ! 

2) Falls man ein solches Programm laufen lassen möchte, ist die 
einfachste Möglichkeit (aber nicht sehr sauber), den Bildschirm¬ 
speicher um einige hundert Bytes nach unten zu verschieben. 
Diese ist aber sehr problematisch, da das Betriebssystem den 
Speicher, wo dann der Bildschirmspeicher sitzt, vielleicht schon 
benutzt. Besser man schreibt sich ein Programm, das den 
Memtop verschiebt, siehe ’ KAPA8.TOS' - MEMORY.S. 

Dieses Problem tritt (nur!) bei ST(E)’s auf, da die MMU des TTs 
auch auf Speicher hinter der 4MB-ST-RAM Grenze zugreifen kann, 
man kann sich mit Hilfe der programmierbaren MMU des 68030 im 
Prinzip an fast jede beliebige Stelle Speicher legen! Jedoch natür¬ 
lich nur, falls man genügend hat, denn Speicher ist wie ein Bettuch, 
wenn man an einer Seite zieht, fehlt es an einer anderen. 


8.1.2 Das Syncmode Register des TT 

(oder wie der Bildschirm plötzlich ganz schwarz wurde) 

Leider hat Atari bei der Entwicklung des TT - Shifters wohl einen 
"klitzekleinen" Design Fehler mit großer Wirkung gemacht. Das Bit 
0 im Syncmode Register des TT, das auf externe Synchronisation 
(für Genlocks etc.) umschaltet, reagiert genau anders herum wie 
bei ST (siehe Teil 2, Kapitel 1), damit wiederum haben die Pro¬ 
grammierer nicht gerechnet, die in ihrem Programm auf die augen¬ 
freundlicheren 60 Hz Bildwiederholfrequenz (wenn im ST das Bit 1 
des Syncmode Registers gelöscht wird) umschalten und dabei das 
Bit 0 des Syncmode Registers auch gleich löschen, denn dann 
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wartet der TT auf externe Synchronisation und darauf kann er dann 
meist lange warten. Dieses kommt einem Absturz des Rechners 
gleich, da kein VBL mehr ausgeführt wird (fast nichts geht mehr). 

Lösung: 

1) 60Hz Umschaltung mit ANDI.B #2,$ffff820A.w durchführen !!! 

2) Um Programme starten zu können, die eine solche Umschal¬ 
tung beinhalten, das Bit 0 des Syncmode Registers per TT - Ti¬ 
mer immer wieder setzen, z.B. dem Programm aus KAP8.TOS, 
SYNCFIX.S. 


8.1.3 Probleme mit Syncscrollern ??? 

Wer sogenannte Syncscroller in eigenen Programmen benutzt, ein 
Verfahren um mit Hilfe des Shift Mode und Sync Mode Registers 
durch geschicktes Umschalten bei ST und damit Öffnen der Bild¬ 
schirmränder bestimmter Zeilen, das nicht vorhandene Video Low 
Byte simuliert (siehe Kapitel über Syncscrolling), also wer Techni¬ 
ken wie Öffnen der Bildschirmränder und Syncscrolling wirklich nö¬ 
tig hat, sollte Routinen anbieten, die alternativ bei unbekannter 
Hardware oder möglichen Timing Schwierigkeiten, z.B. durch 
16Mhz Speeder, die gleiche Funktionen erfüllen, auch wenn das 
Programm in einem solchen Fall vielleicht nicht mehr ganz so toll 
aussieht. 


8.1.3 Man muß auch warten können 

(Probleme mit Warteschleifen) 

Viele Programmierer, die qualitativ hochwertige Spiele von Syste¬ 
men mit mehr Farben (z.B. PC mit VGA) oder einfacher zu erzeu¬ 
gendem Scrolling (z.B. AMIGA) auf einen ganz normalen ST Um¬ 
setzen "müssen", realisieren dies durch exaktes Synchronisieren 
des Prozessors mit dem Bildschirmaufbau. Diese Programme lau¬ 
fen meist nur so lange der Prozessor mit 8 MHz getaktet ist, bei 
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jeder Änderung der Taktfrequenz ändert sich möglicherweise das 
Timing des Prozessors total. Das bedeutet wiederum, daß irgend¬ 
welche Bitschiebebefehle z.B. bei 16 MHz Speedem möglicherwei¬ 
se doppelt so schnell ausgeführt werden, aber NOP’s (no Operation 
- ein Befehl, der nichts als wartet), nicht schneller als zuvor abge¬ 
arbeitet wird. Beim nächst höheren Prozessor z.B. 68030/040 kön¬ 
nen sich die Verhältnisse der Prozessor-Befehle zueinander wie¬ 
derum stark verändert haben. 

Lösung: 

1) Benutze die Timer, um z.B. Farbumschaltungen an der richtigen 
Stelle einsetzen zu lassen oder Warteschleifen zu ersetzen, sie¬ 
he auch dazu mein Kapitel über Timer Programmierung. 

2) Starte mein ’VERZIT.PRG’ in KAPA8.TOS, das mittels des TT Ti¬ 
mers A des MFP den Prozessor so oft unterbricht, daß er nur 
ca. 1/4 bis 1/6 seine Leistung bringt und somit das Spielen be¬ 
stimmter Programme auf dem TT erst wieder möglich macht. 
Für den Falcon gibt es da eine elegantere Lösung, denn dieser 
läßt sich auf ca. 1/2 seiner Leistung drosseln, wenn man das Bit 
0 im undokumentierten Register $FFFF8007 löscht. Das Verän¬ 
dern der Speicherstellen $FFFF8006/7 hat eine große Wirkung 
auf das Verhalten des F030, da diese Register jedoch undoku¬ 
mentiert sind und ich deren Wirkung noch nicht komplett ent¬ 
schlüsseln konnte, hilft nur probieren. Trotz alledem befindet 
sich ein Patch ! 'VERZFAL.PRG' Programm (und diese dürfen be¬ 
kanntlich fast alles benutzen) auf Diskette, das den Falcon030 
seiner Geschwindigkeit beraubt. 


8.1.4 Andere Prozessoren - anderes Stackformat 

8.1.4.1 Stackformat - Was ist das 

Je nach Interrupt legen die 680X0 Prozessoren unerschiedliche 
Daten auf den Stack, um später den regulären Ablauf des Pro¬ 
gramms wieder aufnehmen zu können. So hat der Stack, je nach 
dem welcher Interrupt auszuführen ist, ein anderes Format. 
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8.1.4.2 Das Stackformat 

Motorola redet bei seinem Prozessoren der 68000er Familie von 
Usermode Kompatibilität. Einen einzigen "Design Fehler" (die Aus¬ 
nahme von der Regel) hat sich Motorola dennoch geleistet. Der 
Befehl MOVE From SR (MOVE SR,<ea>), der das Statusregister 
in den Speicher kopiert, ist für alle Prozessoren, außer dem 68000, 
ein Privilegierter Befehl (kann nur im Supervisor Mode ausgeführt 
werden). 

Im Supervisor Mode sieht es mit der Kompatibilitiät zwischen den 
680X0 Prozessoren nicht ganz so "rosig" aus, allerdings liegen die 
Unterschiede an einer Stelle, an der ein "normaler" Programmierer 
eigentlich nicht zu "rütteln" hat, und zwar das Stackformat bei In¬ 
terrupts. Motorola ändert zwar bei der Entwicklung eines neuen 
Prozessors sein Stackformat nicht immer, aber immer öfter! 

Nun, gehen wir etwas ins Detail, am wichtigsten für uns Program¬ 
mierer ist wohl das Default (übliche) Stack Format. Dieses tritt am 
allermeisten auf. 


Default Stack Frame! 

hat bei 68010/20/30/40er Format Code %0000 


Byte 68000 68010/20/30/40 


0 Status Register 

2 PC oberes Wort 

4 PC unteres Wort 

6 


Status Register 

PC oberes Wort 

PC unteres Wort 

Bit 15-12 Format Code %0000 

Bit 11 - 0 Vector Offset 


- Format Code (oberste 4 Bit des 4. Worts) 
gibt Stack Format des jeweiligen Interrupts an 
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Code 

Länge des 
Stackformats 

tritt z.B. auf bei 


in Bytes 


%0000 

8 

Default 

%1000 

58 

Bus Fehler 68010 

%1010 

32 

...68020/30 Short 

%1011 

92 

.. Long 68010/20/30 

%0010 

12 

Division by Zero u.v.m 68020/30/40 

%1001 

20 

Line F 68020/30 

%0001 

8 

Exception Stack Frame 

%0111 

60 

Access Error Stack Frame 68040 

%0011 

12 

Floating-Point Post-Instruction 68040 


- Vector Offset (unterste 12 Bit des 4. Worts) gibt den Abstand des 
aufgetretenen Interrupts in Bytes zur Vector Basis Adresse (steht 
im Vector Basis Register) an. Man kann mit Hilfe dieses Offsets 
z.B. einen Trap Dispatcher schreiben, der alle ankommenden Ex- 
ceptions an die entsprechenden Betriebssystem-Routinen weiter¬ 
leiten kann, da man aus dem Offset/4 ja die Nummer des Traps 
errechnen kann. 

Die neueren TOS Versionen erkennen das geänderte Stack Format 
und passen sich an (ab TOS 1.06). So läßt sich zum Beispiel 
schon in einen 1040 STE ein 68010 einbauen (der bei gleichem 
Takt schon ein wenig schneller ist) allerdings dürften dann einige 
Debugger und Demos nicht mehr laufen. 

Ab TOS 3.0 läßt sich das Stack Format über die System Variable 
Jongframe, die an der Adresse $59e liegt,abfragen - wenn der In¬ 
halt der Variable > 0 ist, kann man davon ausgehen, daß man sich 
in einem System mit Prozessor > 68000 befindet. Diese Variable 
dürfte sogar von den meisten modifizierten TOS-Versionen der 
Hersteller Beschleunigerkarten entsprechend gesetzt oder gelöscht 
werden, da ein großer Teil von Ataris Systemsoftware nur bei ent¬ 
sprechendem Eintrag in Jongframe funktioniert. 
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8.1.5 Die Caches 

- Cache, was ist das ? (kurze Definition) 

Cache ist ein schneller Zwischenspeicher, auf den der Prozessor 
schneller als auf das restliche Ram zugreifen kann. Beim Zugriff 
auf den Speicher testet die Logik auf dem Cache, ob sich der ent¬ 
sprechende Speicherinhalt nicht auf dem Cache befindet, z.B. 
wenn man kurz zuvor schon einmal auf dieselbe Adresse zugegrif¬ 
fen wurde, und greift, falls das zutrifft, auf den schnelleren Cache- 
Speicher zu. 

- Probleme mit DMA Bausteinen bei eingeschaltetem Cache 

Sowohl der 68030 im TT und Falcon030 als auch der MEGA STE 
besitzen Cache - Speicher. Beim 68030 ist es ein interner Prozes¬ 
sor Cache, der aus je 256 Byte Daten- und Befehlscache besteht. 
Im MEGA STE dagegen befindet sich ein externer Cache der als 
Puffer zwischen Prozessor und Speicher um die Performance ei¬ 
ner 16 Mhz getakteten CPU auf das auf 8 Mhz getaktete Board des 
STE zu bringen. Ein 16 Mhz getaktetes Board hätte Atari wohl im 
Vergleich zum Nutzen zuviel gekostet. Außerdem versagen auf 
dem Mega STE auch die meisten der vielen, relativ unsauber ge¬ 
schrieben Spiele nicht ihren Dienst. Wenn mal eins nicht funktionie¬ 
ren sollte, hilft oft TOS 1.0 oder 1.04 ins RAM zu laden. Aber nun 
zurück zum Cache, bei direkter Programmierung der Hardware 
kann es bei angeschaltetem Cache zu Problemen kommen, die so 
ohne weiteres nicht ersichtlich sind. Ein Beispiel wäre die direkte 
Programmierung des Floppycontrollers oder der £GST/ASCI DMA 
(direkt memory access / direkter Speicher Zugriff). Man program¬ 
miert also den DMA Chip, dazu einige Bytes von den Sektoren ei¬ 
ner Diskette zu lesen, dieser legt dann diese Bytes selbständig 
(daher auch DMA) in den Speicher. Währenddessen hat der Pro¬ 
zessor fast keinen Zugriff auf den Speicher. Der Prozessor be¬ 
kommt erst dann den Bus (also den Zugriff auf den Speicher) wie¬ 
der, wenn der DMA-Chip eine Pause macht oder die Übertragung 
in den Speicher beendet wurde. Nun steht im Cache des Prozes- 
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sors möglicherweise noch der vorherige Inhalt des Speichers, den 
man zuvor per DMA verändert hat, das wiederum kann zu fehler¬ 
haft ausgeführten Programmen führen (sprich Bomben), da ein Teil 
des Programms aus dem Cache stammt, ein anderer Teil von der 
Diskette. Diese Probleme treten immer dann auf, wenn Daten im 
Speicher ohne Wissen des Prozessors geändert werden z.B. durch 
Blitter oder anderen DMA-Bausteinen. Bei den heute gängigen 
Beschleuniger-Karten wird zumindest der externe Cache gelöscht, 
wenn der Prozessor den Bus abgibt (das passiert z.B. bei Benut¬ 
zung des DMA Controllers oder des Blitters). Es ist jedoch schwer 
möglich, den 68020/30 in seinem Cachehandling so zu beeinflus¬ 
sen. Beim 68040 wurde daher sogenanntes "bus snooping" imple¬ 
mentiert, der "intelligente Cache“ des 68040 "horcht“ am bus und 
falls ein anderer Prozessor seinen Schreibzugriff bekannt gibt, 
löscht er automatisch die entsprechenden Cache-Einträge. 

Bei Benutzung eines 68020/30 sollte man daher entweder den Ca¬ 
che vor dem DMA Betrieb ausschalten bzw. für ungültig erklären 
oder Überschneidungen von Cache und DMA durch intelligente 
Programmierung vermeiden, besser noch (weil das die sauberste 
Lösung ist) nur Betriebssystem-Funktionen verwenden und die 
Hardware nicht direkt programmieren (wenn das immer so leicht 
ginge!). 

- Selbstmodifizierender Code 

Zuerst möchte ich mal erklären, was das ist! 

Alle Atari Rechner sind sogenannte "von Neumann" Rechner (die 
MAC’s, Amigas, PC’s, NEXT Rechner auch). Bei dieser Art von 
Rechnern liegen Programmcode und Daten im selben Speicher. 
Nun, der Prozessor kann Daten verändern, Speicherzellen löschen 
in denen ein Datum (Einzahl von Daten) vorhanden ist und das an 
jeder Stelle des Speichers! Also auch an den Stellen, wo sich aus¬ 
führbarer Programmcode befindet. Somit ist es also möglich, wä- 
rend des Ablaufs eines Programms das Programm zu ändern um 
somit z.B. die Bedingungen oder Sprungoffset’s von Branch-Befeh- 


128 



Wie bleibe ich kompatibel ? 


len zu ändern und somit vielleicht Stellen im Programm zu modifi¬ 
zieren, die mehrmals ausgeführt werden müssen. Mit Selbstmodifi¬ 
zierende Programmen ist es zwar sehr oft möglich, aus dem Rech¬ 
ner "das Letzte rauszuholen", aber solche Programme sind zum ei¬ 
nen sehr unübersichtlich und damit fehlerträchtig und zum anderen 
Vertragen sie sich nicht mit Caches und Pipelinig (Technik mehrere 
Befehle im Prozessor, wie am Fliesband, zu bearbeiten). Nun hat 
man wieder zwei Möglichkeiten, Programme zu schreiben, die auf 
allen Atari Rechnern (ab ST aufwärts) laufen! Richtungsweisend 
wäre es, Algorithmen (Rechenvorschriften) zu schreiben, die 
schnell genug sind und doch auch ohne die Modifizierung des eige¬ 
nen Programmtextes auskommen, aber das ist gelegentlich 'fast' 
unmöglich. Andererseits könnte man zwei Routinen schreiben, die 
man je nach Prozessortyp verwenden könnte. 


8.2. Das Betriebssystem 
8.2.1 Generelles 

ATARI ist es zumindest gelungen, jede neue Betriebssystem Ver¬ 
sion abwärts kompatibel zu halten, das bedeutet jedoch, daß mögli¬ 
che neue Calls auf den kleineren Versionsnummern nicht laufen. 

Ein Beispiel ist die erweiterte Fileselect Box ab TOS 1.4 (AES 91), 
jede Verwendung in einer älteren TOS-Version erzeugt Bomben! 
Man sollte bei Verwendung solcher neuen Funktion des Betriebssy¬ 
stems zuvor die AES Version Nummer, die bekommt man beim 
’appl_init()’ (AES 10) im 'Global’ Feld zurückgeliefert. Nur die TOS- 
Versionsnummer abzufragen, würde in diesem Fall leider nicht 
ausreichen, da der Benutzer ja ein externes AES ins RAM geladen 
haben könnte. 

Auch hat ATARI die Lage des Betriebssystem von SFC0000 auf 
$E00000 verlagert, womit scheinbar einige Spiele und Demopro¬ 
grammierer niemals gerechnet haben! Obwohl schon durch die in¬ 
terne Struktur des Betriebssystem (außerdem lag es ja bis Mitte 
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1986 im RAM) jedem klar sein mußte, das Positionsänderungen 
ATARI wirklich keine Probleme bereiten dürfte. Die Geräte, die un¬ 
ter TOS laufen, sind eben keine "Homecomputer", denn bei diesen 
Rechnern und nur bei diesen, ist das Springen über absolute Ad- 
dressen nötig. Auch sind undokumentierte Systemvariablen nicht 
ohne Grund undokumentiert! Im Klartext heißt das, immer nur das 
benutzen, was Atari auch wirklich dokumentiert hat, Ausnahmen 
sind dabei natürlich div. Patchprogramme und systemnahe Soft¬ 
ware; diese dürfen natürlich "fast alles" benutzen, da sie nur mit ei¬ 
ner speziellen Rechnerconfiguration laufen müssen. 


8.2.2 Line A 

Für den Prozessor sind alle Befehlswörter, die mit einem $A begin¬ 
nen unbekannt, er löst eine Ausnahmebehandlung (Exception) aus. 

Das Line A Interface ist die softwaremäßige Emulation eines imagi¬ 
nären Grafik-Chips. Über diese Emulation erledigt das VDI seine 
Grafikausgaben. Nun unterstützen die wenigsten VDI Treiber für 
z.B. Grafikkarten die Lina A Grafik, das bedeutet wiederum, daß 
Programme, die Line A Grafiken benutzen, nicht auf diesen Karten 
laufen, was gegen die Verwendung von Line A Variablen spricht. 

In den Dokumentationen von Atari zum TT wird eindeutig empfoh¬ 
len, bei Grafik Ausgaben das VDI zu nutzen, da Line A nur zur 
Kompatibilität mit älteren Systemen ins TT-TOS implementiert (ein¬ 
gebunden) wurde. Im Klartext, Hände weg von LINE A, denn seit 
es div. Programme gibt, die das VDI stark beschleunigen und fast 
100% kompatibel zum Original VDI sind, ergibt es keinen Sinn, in 
Standart Aplicationen (auch in Spielen) die LINE A Routinen zu be¬ 
nutzen. 

Außerdem sind die LINE A Routinen nicht reintrant, d.h. es kann zu 
Problemen kommen, wenn zwei Programme (z.B. unter Multitos) 
auf die Line A Variablen zugreifen, da bei den LINE A Routinen nur 
ein Speicherbereich zur Parameterübergabe vorhanden ist, so daß 
sich die zwei Applikationen, falls mitten beim Aufruf eine Prozess¬ 
wechsel stattfindet, gegenseitig die Parameter zerstören. 
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8.2.3 LINE F 

Die Befehle der FPU (Floating Point Unit bzw. mathematischer Co¬ 
prozessor) beginnen alle mit einem $F, wenn kein Coprozessor 
vorhanden ist, wird ein Interrupt ausgeführt. In diesem Interrupt ist 
es dann möglich, die fehlenden Coprozessor-Befehle zu emulieren 
(nachzuahmen). 

Obwohl der Sinn und Zweck der LINE F von Motorola von Anfang 
an bekannt gegeben wurde, hat selbst ATARI zu Beginn die LINE F 
für AES Aufrufe gebraucht (bis incl. TOS 1.04). Da ist es nicht 
verwunderlich, daß auch einige Programmierer auf die Idee gekom¬ 
men sind, den LINE F Vektor auf einen eigenen Dispatcher (Vertei¬ 
ler) zu richten und von diesem Punkt aus eigene Routinen aufzuru¬ 
fen. Nun spätestens mit dem Erscheinen des TT’s mit eingebauten 
Coprozessors laufen diese Programme nicht mehr, da statt der 
Dispatcher der Coprozessor aufgerufen wird, der dann natürlich die 
vorgesehene Funktion nicht erledigt. 

"Leider" last sich der Coprozessor nicht so einfach abschalten, so 
daß die Programme die LINE F für eigene Zwecke nutzen auf dem 
TT ebenfalls ihren Dienst verweigern. 

Jedes neue Programm sollte es vermeiden LINE F für andere 
Zwecke als Coprozessor Emulationen zu nutzen ! 

Jede Zuwiderhandlung wird mit lebenslanger Inkompatiblität bestraft !!! 


8.2.4 Systeminformationen mit Hilfe des Cookie Jar 

("Keksdose", oder wie Dir Kekse helfen können) 

Ab TOS 1.06 wurde in das TOS das sogenannte "Cookie Jar" in¬ 
stalliert. Der Zeiger auf die Cookies befindet sich an der Adresse 
$5a0. Ab TOS 2.06 bzw. 3.06 konfigurieren sich die Cookies von 
selbst, d.h. das TOS testet die im Computer befindliche Hardware 
und richtet entsprechend die Cookies ein. Aber auch Programme, 
die nach ihrem Start resident (nach "Beendigung“ des Programms 
sind sie immer noch im Speicher) im Speicher bleiben, z.B. Ram- 
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disk und Mausbeschleuniger, können sich in das Cookie Jar eintra¬ 
gen, um einem anderen Programm zu zeigen, daß sie präsent sind 
und entsprechend konfiguriert werden können. 

Ein gutes Beispiel hierfür ist z.B. NVDI, dessen Accessory, das 
man zum Einstellen der Parameter benötigt, sich nur installiert, 
wenn NVDI auch installiert ist und das erkennt es natürlich an dem 
Eintrag im Cookie Jar. 

Funktionsweise 

Falls sich an der Adresse, auf die $5a0 zeigt, eine Null befindet, ist 
noch kein Cookie Jar installiert. Das testende Programm läuft also 
in einem Atari ab, dessen BIOS keine Cookies installiert hat oder 
irgend jemand hat gemeinerweise alle Cookies gelöscht... 

Ein Cookie (Eintrag im Cookie Jar) besteht aus zwei Langworten. 
Das erste Langwort sollte eine eindeutige Nummer sein, die in ir¬ 
gendeiner Weise kenntlich machen soll, von welchem Programm 
das Cookie stammt z.B. ’NVDI’. Das erste Zeichen eines solchen 
aus ASCII-Zeichen bestehenden Strings (keine nationalen Sonder¬ 
zeichen !) darf kein (underscore, $5f) sein, da so das BIOS sei¬ 
ne Cookies kennzeichnet. Der String darf keine Variante des Wor¬ 
tes ’Cookies’ sein, da das laut Atari zu offensichtlich wäre und auf 
keinem Fall den Eintrag an sich beschreiben würde, es wäre eben 
so als würde man eine Variable in einem Programm ’var’ nennen. 
Wenn man ein bestimmtes Cookie sucht, ist die Suche an der Stel¬ 
le zu Ende, wenn das erste Langword Null ($00000000) ist, denn 
das ist dann das Ende der Cookie Jar. 

Das zweite Wort ist dann die Information zum Cookie ! 
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z.B. 1. Langwort 2. Lang wort 

BIOS: Standard Cookie Installation ab TOS 1.06 


_CPU 

0,10,20,30,40 (Dezimal) 
bedeutet 68010/20/30/40 etc. 

_VDO 

Video Hardware 
oberstes Wort 

0 - ST, 1 - STE, 2 - TT, 


q 3 - Falcon 


_SND 

Tonerzeuger 

BIT 0 - Gl/Yamaha 

BIT 1 - Stereo DMA 

BIT 2 -16 Bit CODEC 

BIT3 -DSP 

BIT 4 - Connection Matrix 


Leider hat ATARI kein Bit für LMC 1992 und Microwire Interface im 
Sound Coockie definiert! 


_MCH 

Computertyp 
oberstes Wort 

0-520 ST, 1040 ST 

1 - STE 

2 - TT 

4 - Falcon 


Die Abfrage der Cookies wurde in verschiedenen Beispiel Applica- 
tionen schon gezeigt (z.B. Argon 4)! 

Das Cookie Jar ist also eine Möglichkeit um herauszufinden, auf 
welcher Plattform das Programm gerade läuft. Es gibt noch div. 
andere Cookies, die aber für Spieleprogrammierer in der Regel un¬ 
interessant sind. 
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8.3. MULTI TOS 

das offizielle Multitasking Betriebssystem von Atari 

Jeder, der jetzt nicht gerade Action Spiele schreibt oder schnelle 
Animation in seinem Programm benötigt, sollte versuchen, seine 
Programme in Fenstern laufen zu lassen. Gerade Adventures und 
Simulationen bieten sich an, so programmiert zu werden, daß ihre 
Grafikausgaben in Fenster erfolgen. Dazu gehört natürlich, nicht 
direkt in den Bildschirmspeicher zu schreiben, sondern daß Be¬ 
triebssystem alle Ein/Ausgaben tätigen zu lassen. Das erhöht stark 
den Nutzen eines Spieles, da selbst die etwas "älteren Semester" 
gern mal ein "Spielchen" wagen, wenn der Rechner im Hintergrund 
druckt oder seinem User (Benutzer) andere wichtige Tätigkeiten 
abnimmt. 

Nun gehört zur GEM Programmierung ein bestimmtes Grundwis¬ 
sen über AES und VDI, dieses zu vermitteln, würde die Seitenzahl 
dieses Buch nahezu verdoppeln, da es aber seit MULTI TOS sin- 
voll ist, mehr über das GEM zu wissen, wäre es empfehlenswert 
sich ein solches Buch (siehe Anhang B) zuzulegen und das auch 
für Spieleprogrammierer! 

8.3.1 Benutze nie Speicher, der Dir nicht gehört 

Unter Multi TOS ist es möglich, Speicherplatz, den man sich vom 
GEMDOS anfordert oder in dem das Programm läuft, bestimmte 
Attribute zu geben. Es ist damit möglich, laufende Prozesse vorei¬ 
nander zu schützen, aber auch unter bestimmten Bedingungen zu¬ 
gänglich zu machen. Das funktioniert effektiv allerdings nur bei 
Rechnern, die einen Prozessor mit/und PMMU (programmierbarer 
Speicherverwaltungsbaustein) beinhalten, wie TT und Falcon. Multi 
TOS kennt vier Arten von Speichern. 

1. Privaten. Das ist Speicher, der nur von dem Programm (und 
dem Betriebssystem) benutzt werden kann. 
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2. Globalen. Dieser Speicher ist ungeschützt, jeder darf von ihm 

lesen und ihn beschreiben. 

3. Super. Darf von anderen nur im Supervisor Modus ange¬ 

sprochen werden. 

4. Privater (nur lese). 

Jeder darf seinen Inhalt lesen, aber keiner darf ihn 
beschreiben. 

Programme, deren Programmkopf nicht entsprechend modifiziert 
wurde, laufen "nur" in ihrem eigenen Speicher. Aber selbst wenn 
man die entsprechenden Bits im Programmkopf ändert, kann man 
damit allerhöchstens den eigenen Speicher für Programme zugäng¬ 
lich machen, andere Speicherbereiche können trotz allem ge¬ 
schützt sein ! Ein Zugriff auf fremden Speicher könnte somit zum 
"Russischen Roulette" werden. Also immer schön den Speicher, 
den man benutzen möchte, beim Betriebssystem verlangen. Nähe¬ 
re Informationen über Multi TOS sind im Anhang X zu finden. 


8.4 Ataris Game/Entertainment 
Software Guidelines 

Zur Veröffentlichung des Falcon030 hat Atari an die Entwickler von 
Spielesoftware erstmals Richtlinien zur Programmierung herausge¬ 
geben. 

Um es dem Leser zu vereinfachen, habe ich diese ins Deutsche 
übersetzt. 


Die folgenden Punkte sollen befolgt werden... 

- Installierbar auf Festplatte 

- Soll von jeder Bildschirmauflösung zu starten sein 
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- Der Benutzer sollte mit einer einzigen ausführbaren Datei kon¬ 
frontiert werden, die dazugehörigen Daten, Highscore etc. sollen 
sich in einem dazugehörigen Ordner befinden. 

- Dem Benutzer sollte es möglich sein, das Programm zu verlas¬ 
sen und den Desktop wieder so vorzufinden wie er ihn verlassen 
hat. 

- Verwende den verbesserten Joystick für alle Spiele, für die Joy¬ 
sticks nötig sind; Regler wie der CX 40 sollten nicht unterstützt 
werden. 

- Idealerweise, wo möglich, lassen Sie Ihr Spiel in einem Fenster 
laufen; passend für die Benutzer, die unter einer Multi - Tasking 
Oberfläche spielen wollen (und z.B währenddessen eine Datei 
von einer Mailbox übertragen) 

- Wir nehmen an, daß die meisten Benutzer die 640*480 Punkte 
Auflösung mit 256 Farben nutzen, bitte denken sie daran. 

- Wenn sie den VDI Aufruf, vr_trn_fm() (transform form) benutzen, 
können sie leicht Bild-Daten vom Standard-Format in das Format 
der gerade laufenden Auflösung wandeln. 

Ich habe die Übersetzung so genau wie möglich und so frei wie nö¬ 
tig vorgenommen, um Mißverständnisse zu vermeiden. 


8.4.1 Was hat das nun zu bedeuten 

zu Punkt 1 

Kein Diskettenkopierschutz aber entsprechende Installationspro¬ 
gramme auf den Disketten zum Spiel. 
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zu Punkt 2 

Das ist schon komplizierter, erst recht, wenn man direkt auf den 
Bildschirmspeicher zugreift und parallel dazu das VDI benutzt oder 
auf ein Monitor benutzt wird, der nur diese Auflösung benutzen 
kann (z.B. SM124) und man daher nicht umschalten kann. Da nutzt 
auch kein vt_trn_fm(), da dieser VDI Aufruf nicht dithert, also man 
in monochrom dann nicht mal annähernd erkennen kann, was es 
vorher mal für ein Bild war, was man da umgewandelt hat. Der 
vr_trn_fm() ist also nur brauchbar, um von Auflösungen mit weni¬ 
ger Bitplanes auf Auflösungen mit mehr zu konvertieren. 

zu Punkt 3 

Das sollte, wenn Punkt eins befolgt wurde, kein Problem mehr 
sein. 

zu Punkt 4 

Heißt soviel wie bitte keine Programme, "bei welchen man den 
Rechner mit einem Pflasterstein beschmeißen muß" damit er das 
Programm beendet. Also schön alles retten (Vektoren, Palette etc) 
und nach der Beendigung des Programms wieder zurückschreiben. 

zu Punkt 5 

Atari verkauft demnächst verbesserte Joysticks, die an die zusätz¬ 
lichen Ports am 520/1040 STE/Falcon030 passen. Diese sollen 
demnächst vorrangig verwendet werden (mein Kommentar dazu 
folgt noch) 
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zu Punkt 7 

Bisher habe ich noch keine Möglichkeit entdeckt, Action Spiele 
bzw. flackerfreie Animationen in einem Fenster unterzubringen (da 
müßte sich Atari noch etwas einfallen lassen) insofern gibt es nur 
wenige Arten von Spielen, die in ein "Fenster passen" z.B. Karten¬ 
spiele und einfache Adventures oder Spiele, bei denen ein bißchen 
Flackern bei der Animation nicht so tragisch ist. 

zu Punkt 8 

Spiele in Super - VGA Auflösung wären schon nicht schlecht, aber 
dazu braucht man entweder ein schnellere VDI (als das in den 
ROM’s vom Falcon und allen anderen ATARIs) oder muß den Blit- 
ter des Falcon030 per Hand programmieren. 

zu Punkt 9 

Siehe, was ich zu Punkt zwei geschrieben habe. 

Hier der Aufruf des vr_trn_fm() oder auch vr_trnfm(). Der Copy - 
Transform - Form ermöglicht es, das gerätezpezifische Format in 
ein Standard Format umzuwandeln und umgekehrt. 

Deklaration in C: 

void vr_trnfm(WORD handle, MFDB ‘psrcMFDB, MFDB ‘pdesMFBD) 

{ 

Lptr (psrcMFDB); 
i_ptr2 (pdesMFDB); 
contrl [0] = 110; 
contrl [1] = contrl [3] = 0; 
contrl [6] = handle; 
vdi(); 

} 
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GEM - Felder: 


contrl 110 Nummer von Transform Form 

contrl+2 0 

contrl+4 0 

contrl+6 0 

contrl+8 0 

contrl+12 handle 

contrl+14 Zeiger auf MFDB Quellraster 

contrl+18 Zeiger auf MFDB Zielraster 

Format der MFDB (memory definition Block): 


16 Bytes mit den Funktionen 


Langwort 

Wort 

Wort 

Wort 

Wort 

Wort 


Speicheradresse der Rasters 
wenn 0, aktueller Bildschirm 
Breite des Rasters 
Höhe des Rasters 

Größe des Bildschirmspeichers einer Plane für eine 
Zeile in Worten z.B. 20 Worte für ST - niedrig 
0 - Gerätespezy 1 - Standard 
Menge der Bitplanes z.B. 4 = 16 Farben 


dann 3 reservierte Wörter 

Das Standardformat ist planeweise organisiert. Das bedeutet, daß 
jede Bitplane komplett (ähnl. wie beim AMIGA der Bildschirmspei¬ 
cher organisiert ist) in einem Stück hintereinander abgelegt ist, wo¬ 
bei die Organisation der Planes von links nach rechts d.h. 1. Plane 
Pixel 0,0 wird durch das 16. Bit des ersten Worts der Plane reprä¬ 
sentiert. In Monochrom stimmt das Standard Format mit dem gerä¬ 
teabhängigen Format (also so wie es im Bildschirmspeicher ange¬ 
ordnet ist) überein. Allerdings erlaubt es das VDI prinzipiell nicht, 
daß man irgendwelche Annahmen über das Format des Bild- 
schimspeichers macht. 
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8.4.2 Mein Kommentar zu ATARIs Guidelines 

Der Falcon030 ist kein Macintosh Rechner, er deckt ein komplett 
anderes Marktsegment ab. Dieses Marktsegment ist beherscht von 
Konsolen mit superschnellen Grafiken und PC’s mit Rechnerlei¬ 
stung zu Dumpingpreise. Insofern muß ATARI, und nur der Her¬ 
steller kann dem Programmierer diese Möglichkeiten geben, eine 
Unterstützung durch das Betriebssystem bieten, Animationen lau¬ 
fen zu lassen und Spiele zu programmieren, die auch auf der 
nächst höhren Rechnergeneration laufen. Es darf einfach nicht 
passieren, daß auf dem TT die Spiele nicht laufen, nur weil ATARI 
vergessen hat, die Joystickports des 1040 STE einzubauen und bei 
der nächsten Rechnerfamilie vorschreibt: Jetzt nur noch mit den 
neuen Ports! Auch muß es möglich sein, die Spiele so zu program¬ 
mieren, daß sie sowohl auf dem Falcon als auch auf einem ST mit 
Grafikkarte laufen. Da muß ATARI einfach eine Schnittstelle z.B. in 
Form eines META-Treibers liefern, die jeder Kartenhersteller auf 
seiner Karte implementieren "muß", die Sachen wie Page Flipping 
und/oder Synchronisieren der Grafikausgabe mit dem Bildaufbau, 
u.v.m. ermöglicht, um somit eine Standardisierung zu erreichen, 
die die Aufwärtskompatibilität von Animationsprogrammen, Spielen 
und Multimedia bei unter diesen Gesichtspunkten geschriebenen 
Programmen sicherstellt. Nur so, denke ich, ist ein Überleben die¬ 
ser Rechnerfamilie, die unbestreitbar die Brücke zwischen 
PC/AMIGA und Macintosh/NEXT schlägt, möglich. 
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TEIL II 


Live could be much easier, 
ifl had the source code 

Autor: unbekannt 


Was erreiche ich wie auf dem ATARI ? 

Sie haben sicherlich schon Spiele und Demos gesehen, die auf 
dem Bildschirm Effekte zeigen, die sie den Atari Rechnern gar 
nicht zugetraut hätten und statt ohrenbetäubendem Piepsen erlese¬ 
ne Sounds "zum Besten gegeben haben". Vieles davon ist gar nicht 
so schwer zu programmieren, wenn man erst mal weiß wie ! 

Auch kann der interresierte Beobachter leicht erkennen, wie 
schlecht einige Programmierer, die Spiele von anderen Systemen, 
auf die ATARI Serie umgesetzt haben ! 

Dieser zweite Teil des Buches soll sowohl dem Hobbyprogrammie- 
rer, der guten Sound und weit mehr als 16 Farben in seine Pro¬ 
gramme integrieren will, das nötige Handwerkszeug bieten, als 
auch dem Profi, der nicht weiß, wie er diese oder jene "Spielerei" 
ohne Verluste auf den ATARI übertragen kann, helfen, die Resour- 
cen der Ataris voll auszuschöpfen. 

Nicht zuletzt soll gezeigt werden, daß man die Fähigkeiten der neu¬ 
en ATARI Modelle nutzen kann ohne die alten ST’s zu vernachläs¬ 
sigen. 
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B.I.Die Grafikhardware 

der ATARI ST/STE/TT/Falcon030 Modelle 

Als der ATARI ST Ende 1985 auf den Markt kam, sprach die Pres¬ 
se von hervorragenden Grafikmöglichkeiten; das ist auch nicht wei¬ 
ter verwunderlich, da die damals erhältlichen IBM PC kompatiblen 
Rechner nur mit CGA - Grafikkarten ausgerüstet waren, die bei ei¬ 
ner Auflösung von 320*200 gerade mal 4 Faben und bei 640*200 
nur zwei Farben darstellen können. Selbst damals gebräuchliche 
Homecomputer C64/C 128/ATARI XL/Schneider CPC/ ZX Spec¬ 
trum usw. waren kaum dazu fähig, den ATARI in Auflösung und 
Farbauswahl zu übertreffen. Nur der ein halbes Jahr später auf 
dem Markt erschienene AMIGA 1000, der eigentlich als Edelspiel¬ 
konsole konzipiert war, übertraf in Sachen Grafik die ST Serie. Da 
der AMIGA 1000 in seinen Anfangszeiten mehr als doppelt so teuer 
war wie der 260 ST, war er keine direkte Konkurrenz. Das hat sich 
allerdings spätestens mit dem Erscheinen des AMIGA 500 geän¬ 
dert, der im Moment eher eine Konkurrenz zu den Spielkonsolen 
darstellt, er somit nach mehr als 5 Jahren endlich seiner Bestim¬ 
mung gefolgt ist. Auch bringen heutige PC’s mit VGA oder besser 
noch Super-VGA-Karten Grafiken, die man einem IBM-PC-Kompa- 
tiblen vor einigen Jahren gar nicht zugetraut hätte. Jedoch läßt sich 
mit einigen Tricks und Kniffen weitaus mehr aus dem ATARI her¬ 
ausholen als die Werte der Standardauflösungen vermuten lassen, 
zudem hat ATARI es mittlereile geschafft, auch Computer mit VGA 
ähnlichen oder noch besseren grafischen Möglichkeiten zu konstru¬ 
ieren. 
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1.1 Grafik Hardwareregister 

Achtung ! 

Die Änderungen der Hardwareregister des Falcon werde ich am 
Ende dieses Kapitels extra beleuchten, weil Atari seine Politik alles 
zu dokumentieren zu Gunsten der Kompatiblität mit späteren Gerä¬ 
ten geändert hat. 

Darstellung der Register und deren Bedeutung: 

in folgender Reihenfolge 

Adresse: $XXXXXXXXX 

Länge : L/W/B = 32/16/8 Bit 

Bits : %XXXXXXXXX wobei 

X - nicht belegt 
n - belegt bedeutet 

Zugriff : RO =Read only/nur lesbar 

RW =Read and Write / beschreiben und lesen möglich 
W =Write/beschreiben aber nicht immer lesen möglich 

Label : Gebräuchliches Label in Symboltabellen von Debuggern 

und Programmen 
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1.1.1 Register und deren Funktionen 

Videokontroller (Shifter) 

Video Basis Register: 


High - byte 
$ff 8201 

B 


%nnnnnnnn 

RW 

vbaseh 

Mid - byte 
$ff 8203 

B 


%nnnnnnnn 

RW 

vbasemid 

Low - Byte (nur STE/TT) 



$ff 820c 

B 

STE 

%nnnnnnnX 

RW 

vbaselo 



TT 

%nnnnnXXX 




Das Beschreiben dieses Registers verändert die Speicheradresse 
von der der Videochip seine Bilddaten holt. Die Änderung wird erst 
beim nächsten Bildaufbau vom Shifter übernommen. Beim der ST 
Serie ist das die einzige Möglichkeit, den Bilschirmspeicher zu ver¬ 
schieben, auch läßt das Fehlen eines Registers für die unteren 8 
Bit bei der ST Serie nur Bildschirmadressen an 256 Byte Grenzen 
zu, was wiederum das horizontale Scrolling erschwert; das wurde 
bei STE/TT geändert. 

Bei STE läßt sich die Bildschirmadresse mit dem ’Low byte’ auf 
Wort-Grenzen bringen, beim TT auf 64 Bit-Grenzen. 

Video Adress Counter: 

(Achtung wurde in einigen Büchern, im Bezug auf den TT, falsch beschrieben) 

High - byte 

$ff 8205 B %nnnnnnnn ST RO vcounthi 

STE/TT RW 

Mid - byte 

$ff 8207 B %nnnnnnnn ST RO vcountmid 

STE/TT RW 

Low - byte 

$FF 8209 B ST/STE %nnnnnnnX im ST RO sonst RW vcountlo 
TT %nnnnnXXX STE/TT RW 
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Bei der ST-Serie kann man in diesen Registern nachlesen, an wel¬ 
cher Stelle im Bildschirmspeicher sich der Videochip gerade befin¬ 
det. Das kann man z.B. dazu nutzen, um eine bestimmte Stelle ab¬ 
zupassen z.B. die Mitte einer Zeile oder überhaupt eine bestimmte 
Zeile (das Warten auf eine bestimmte Zeile geht mit Hilfe des Ti¬ 
mers B viel eleganter als mit Hilfe dieser Register). 

Beim STE ist es auch möglich, die Video Adresscounter zu (das 
erste Bit des ’Low - byte’ wird ignoriert) beschreiben, mit ihnen ist 
es möglich, Split - Screen Darstellungen und (mit Hilfe zusätzlicher 
Register) auch voneinander unabhängig scrollende Streifen auf 
dem Bildschirm zu realisieren und das ohne größeren Rechenauf¬ 
wand. 

Beim TT sind diese Register ebenfalls zu beschreiben, allerdings 
werden die 3 ersten Bits des ’Low - byte’ ignoriert. Das Ignorieren 
der unteren 3 Bits hat seinen Ursprung in der ausgeklügelten Video 
Hardware des TT. Um Timing Schwierigkeiten der CPU auf den 
Speicher zu umgehen, ist das Video - RAM des TT für den TT- 
Shifter 64! Bit breit, der Shifter liest also beim Zugriff auf das Video 
RAM immer volle 64 Bit und stellt diese dar. 

In der Zwischenzeit darf die CPU auf den Speicher (ST - RAM) 
zugreifen, was laut den Unterlagen ein optimales Bustiming in ei¬ 
nem Wechsel Shifter/Processor von 250 ns bedeuten würde, was 
wiederum 0 Waitstaits (Wartezeiten beim Zugriff auf das RAM) für 
einen TT mit 16 MHz 68030 (bzw. ca. >10% Wartezeit durch Über¬ 
schneidungen CPU mit der VIDEO DMA) bedeutet hätte, allerdings 
wurden "in letzter Sekunde" alle TT mit einer 32 MHz-(Taktfre- 
quenz, die die möglichen Taktzyklen pro Sekunde bestimmt) CPU 
ausgerüstet. 

Beim Beschreiben der Video Adress Counter des TT, nimmt der TT 
die Änderung erst an, wenn er die letzten 64 bit angezeigt hat; das 
macht den Versuch, mitten in einer Zeile auf einen anderen Bild¬ 
schirmspeicherbereich umzuschalten, etwas komplizierter. 

"'ACHTUNG**' diese Eigenschaft des TT ist von ATARI nicht dokumentiert 
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Das Sync-Mode-Register 

$ff 820a B ST/STE %XXXXXXnn RW syncmode 
TT %XXXXXXXn 

Bit 0 ist für die Umschaltung auf externe Synchronisation zustän¬ 
dig, wenn es beim ST/STE gelöscht ist, wird der Video Prozessor 
intern synchronisiert (also ganz normal), wenn es gesetzt ist, ex¬ 
tern (von außen) z.B. von einem Videorecorder für Genlock An¬ 
wendungen. Beim TT wurde die Bedeutung des Bits unglücklicher¬ 
weise invertiert. 

Bit 1 ist bei ST/STE für die 50/60 HZ Umschaltung zuständig, aller¬ 
dings ist es mir bei einigen 1040 STE schon öfter passiert, daß sie 
bei der Umschaltung von 60 auf 50 Hz die Bitplanes nicht mehr 
ganz in richtiger Reihenfolge angezeigt haben. Dieses Bit erfüllt 
durch geschicktes Setzen und Löschen an bestimmten Stellen des 
Bilschirms noch einen anderen Zweck, denn mit ihm ist es möglich, 
sogenannte Fullscreen Darstellungen zu realisieren. Beim TT ist 
dieses Bit nicht belegt und wird folglich ignoriert (jedoch sollte man 
sich niemals darauf verlassen, daß bestimmte Bits in Registern 
auch weiterhin ignoriert werden). 


ST kompatible Farbregister: 

r=rot/g=grün/b=blau 

Groß ’R’ bzw. ’G’ bzw. ’B’ repräsentieren das niederwertige (das 
was am wenigsten ändert) Bit pro Nibble (4 bit) beim STE/TT. 

$ff 8240 W ST %XXXX Xrrr Xggg Xbbb RW colorO 
STE/TT %XXXX Bbbb Gggg Rbbb 
bis 

$ff 825e colorl 5 

liegen in Wortweise hintereinander! 
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Die Farbregister enthalten die Farbwerte aus den 512 bzw. 4096 
Farben, die den 16 Farben z.B. in der niedrigen ST/STE Auflösung 
den 16 Farben zugeordnet werden. Änderungen der Farbregister 
machen sich auf dem Bildschirm sofort! bemerkbar, so daß man 
mit ein wenig Aufwand bis zu 48 Farben in einer Zeile darstellen 
kann und in jeder Zeile 46 neue Farben. Für die meisten Anwen¬ 
dungen reicht es jedoch, ein oder zwei Farbregister pro Zeile oder 
mal alle 16 Register mitten im Bild zu wechseln. Wie man sehen 
kann, sind beim ST von jedem Nibble (4Bit), das die Grundfarben 
R-rot G-grün B-blau im Farbregister repräsentieren nur 3 Bit ge¬ 
nutzt, das macht 8-Bit Kombinationen pro Grundfarbe, was wieder¬ 
um 8 hoch 3 Farben, also 512 Farben sind. 

Beim STE wird zusätzlich noch ein niederwertiges Bit vom Shifter 
ausgewertet, dieses Bit liegt an ungewohnter Stelle, und zwar an 
dem jeweils 4. Bit der Farbnibbles. Die Palette des STE ist damit 
weitgehend ST kompatibel. 

Die ST/STE kompatible Palette im TT ist im Prinzip ein Fenster 
aus der TT Palette, die 256 Farbregister beinhaltet. Bei der 256 
Farbpalette sind sogar die Bits wieder in der richtigen Reihenfolge, 
d.h. das niederwertigste Bit ist das 1. Bit pro Nibble. 


Das ST Shift-Mode-Register 


$ff 8260 B %XXXXXXnn 

RW 

shiftmd 

Bitkombination 00 

320*200 

4 Bitplanes 

16 Farben 

01 

640*200 

2 

4 

10 

640*400 

1 

Monochrom 

11 

Reserviert 




Bewirkt die Auflösungsumschaltung! Dieses Register reagiert so¬ 
fort! d.h. man kann z.B. die Auflösung mitten in einer Zeile (siehe 
GFA Raytracer) umschalten. 
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Das TT-Shift-Mode Register (nur TT) 

$ff 8262 W %sXXh Xmmm XXXX pppp RW shift_tt 

pppp (4 Bit) gibt das Fenster an, in das die ST Palette eingeblendet 
wird, die ST Palette läßt sich somit in 16er Schritten in der TT Pa¬ 
lette verschieben. Bei einem Zugriff auf einer der beiden Paletten 
wird, falls es sich um ein Palettenregister handelt, das sich im hier 
eingestellten Fenster befindet, das Register in beiden Paletten ge¬ 
ändert. 


mmm (3 Bit) gibt die Auflösung an (änl. ST-Shift-Mode-Register) 


Bitkombinationen: 


000 320*200 
001 640*200 
010 640*400 
011 Reserviert 
100 640*480 
010 Reserviert 

110 1280*960 

111 320*480 


4 Bitplanes 
2 
1 

4 

1 

8 


16 Farben 
4 

Duochrome 

16 

Monochrome 
256 Farben 


Achtung: auch die reservierten Auflösungen bringen ein Bild auf 
den Schirm! 

Modus 3 (011), stellt 320*200 Punkte mit schätzungsweise 16 Far¬ 
ben dar, allerdings sind die Bitplanes so verdreht, daß ich mich da 
auch irren könnte ! einfach mal ausprobieren. 

Modus 5 (010), hat 640*480 Punkten mit zwei Bitplanes, also 4 
Farben, benötigt jedoch 4 Bitplanes, die Planes 3 und 4 werden 
ignoriert aber trotzdem vom Shifter eingelesen. Ich dachte zuerst, 
daß dieser Modus 1280*480 Punkte hätte, wegen seinem hohen 
Speicherbedarf - wäre schön gewesen ! 

Diese letzten beiden Modi sind von ATARI nicht dokumentiert, also 
nur was für Demo-Programmierer, die damit spezielle Effekte er¬ 
zielen wollen. Diese zusätzlichen Auflösungen lassen sich nicht mit 
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den entsprechenden Xbios Aufrufen (5 - Setscreen) erreichen, da 
bei einem Aufruf dieser Auflösungen der Atari Bomben wirft, war- 
scheinlich stürzen die Line A Variablen, VT 52 Emulation etc ab, da 
es für den Bildschirmtreiber unbekannte Modi sind. 

h (1 Bit) schaltet auf den Hyper-Mono-Mode ! 

d.h. es besteht eine Auswahl aus 256 Graustufen und nicht mehr 
aus 4096 Farben, wobei das blaue Nibble in den Farbregistern die 
unteren 4 Bit und das grün Nibble die oberen 4 Bit der 8 Bit Grau¬ 
stufen Palette sind. Die 4 Bit, die für den Rot-Wert im Palettenregi¬ 
stern zuständig sind, werden in diesem Modus ignoriert. Damit ist 
im 320*480*8 Mode eine echte Graustufen-Darstellung möglich ! 

S (1 Bit) Sample & Hold-Mode 

Beim Setzen eines Pixels mit einer Farbe ungleich der Hinter¬ 
grundfarbe, wird diese bis zu Ende der Zeile aufgefüllt, falls nicht 
eine andere Farbe zwischen dem ersten gesetzten Pixel und dem 
Rand gesetzt wird, sonst wird diese bis zum Rand gezeichnet. Da¬ 
bei wird nicht der Bilschirmspeicher verändert sondern der Video¬ 
prozessor "merkt" sich jeden Wert einer Zeile, die ungleich der 
Hintergrundfarbe ist und stellt diesen dar, bis er auf eine andere 
Farbe trifft, die er sich merken kann. Jedoch "merkt" sich der Vi¬ 
deoprozessor die Farben nur bis zum Ende einer Zeile. 
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TT Farbpalettenregister (nur TT) 

r=rot / g=grün / b=blau 

$ff 8400 W %XXXX rrrr gggg bbbb RW TT_colO 
bis 

$ff 85fe W %XXXX rrrr gggg bbbb RW TT_col255 

groß ist die CLUT (Color-Look-Up-Table) des TT, sein Inhalt wirkt 
sich sofort nach dem Beschreiben auf den Bilschirm aus. Wenn der 
Hyper-Mono-Mode aktiviert ist, wird das Rot-Nibble ignoriert. 


Register zum Hardwarescrolling (nur STE/F030) 

Pixel-Offset 

$ff 8256 B %XXXX nnnn RW hscroll 
Zeilenbreite 

$ff 820f B %nnnn nnnn RW linewid 

Mit diesen beiden Registern, in Verbindung mit dem ’vbaselo’, ist 
es möglich, virtuelle Bildschirme zu erzeugen, daß sind große Bild¬ 
schirme, die sich im Speicher befinden von denen nur ein Aus¬ 
schnitt auf dem Monitor dargestellt werden kann. Dabei kann dann 
mit Hilfe dieser Register der Ausschnitt fast ohne Verschwendung 
jeglicher Rechenzeit durch kopieren von Bildschirmausschnitten, 
der sichtbare Bildschirm im Virtuellen, in 1 (bei Bedarf auch mehr) 
Pixel Schritten, gescrollt werden. 

Bei allen von mir getesteten STE's funktionierte das ’hscrolf Regi¬ 
ster nur in der niedrigen Auflösung einwandfrei, in der mittleren und 
hohen Auflösung erzeugte das Zurücksetzen des Registers von ir¬ 
gendeinem Wert auf Null ein Monitorbild, bei dem die Zeile in den 
Zeilenrücklauf hineinreichte. Man kann diesen Fehler nur umgehen, 
wenn man in diesen beiden Auflösungen nur Werte ungleich Null in 
das ’hscroll’ Register schreibt. 
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1.1.1 Betriebssystem Funktionen zum erreichen der Videoharware 

Mein Dank geht an dieser Stelle an Herrn Kowalewski von ATARI 
Deutschland, für das flotte Zusenden der Falcon030 Entwickler- 
Unterlagen und Software. 

Nomenklatur: 

WORD =16 Bit 
LONG =32 Bit 

VOID = Dummy, d.h. keine Rückgabe 
* = Zeiger auf 

Beispiel: 

XBIOS 5 

VOID Setscreen(LONG log, LONG phys, WORD rez, WORD mode) 
ist 


move.w 

#mode,-(sp) 

move.w 

#rez ,-(sp) 

move.l 

#phys,-(sp) 

move.l 

#log ,-(sp) 

move.w 

#5 ,-(sp) 

trap 

#14 

lea 

$ e (sp),sp 


Rückgabe erfolgt gegebenenfalls ins Register DO. 


XBIOS 2 

LONG Physbase() 

Gibt Adresse des momentan angezeigten Bildschirms zurück ! 

XBIOS 3 
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LONG Logbase() 

Gibt Adresse des momentan vom Grafiktreiber angenommenen 
Bildschirmspeichers zurück! 


XBIOS 4 (nur ST(E)/TT Auflösungen) 

WORD Getrez() 

Gibt den momentanen Grafikmodus zurück (funktioniert beim 
FALCON030 nur in den ST kompatiblen Modi einwandfrei) 


XBIOS 5 

VOID Setscreen(LONG log, LONG phys, WORD rez, WORD mode) 
Zum Setzen von: 

phys , des anzuzeigenden Bildschirmspeichers (siehe XBIOS 2) 
log , der zu beschreibenden Bildschirmspeicher (siehe XBIOS 3) 
rez , Bildschirmauflösung ST(E)/TT Auflösungen keine voll TT 
kompatiblen Auflösungen auf dem Falcon030 möglich, 
mode , F030 Auflösungen (siehe XBIOS(88)) 

-1 für einen der Parameter bedeutet keine Änderung 
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XBIOS 6 (nur ST(E) und TT bis 16 Färb Auflösung) 

VOID Setpalette(LONG ‘Palette) 

‘Palette, Zeiger auf ein Array mit 16 Wörtern, die die Werte für 16 
Farbregister enthalten. 1 WORT hat folgendes Format: 

ST %XXXX Xrrr Xggg Xbbb 
STE/TT %XXXX Bbbb Gggg Rbbb 

r=rot, g=grün, b=blau 

RGB = niederwertigstes BIT rot/grün/blau 

Wird erst beim nächsten VBL gesetzt 

XBIOS 7 (nur in ST(E) und TT bis 16 Färb Auflösungen) 

WORD Setcolor(word colornum, word color) 

colornum , (0..15) Nummer des Palettenregisters 
color , siehe XBIOS 6 

gibt bisherigen Wert des Farbregisters zurück. 


XBIOS 80 (nur TT) 

WORD EsetShift(WORD shiftMode) 
shiftMode 

Bit: 0..3 Nummer des Farbregisters 
8.. 10 Auflösung 

12 Wenn gesetzt, Hypermono (256 Graustufen) 

15 Smear Modus 

gibt alten Wert zurück. 
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XBIOS 81 (nur TT) 

WORD EgetShift() 

gibt ein 16 Bit zurück, wobei: 

Bit: 0..3 Nummer des Farbregisters 
8.. 10 Auflösung 

12 Wenn gesetzt, Hypermono (256 Graustufen) 

15 Smear Modus 

siehe auch $ffff8262 shift_tt Kapitel B.1.1.1. 


XBIOS 82 (nur TT) 

WORD EsetBank(WORD banknum) 

banknum, Nummer des benutzten Fensters in der TT 256 Farb-Pa- 
lette (16 Register weise), bei negativer 'banknum' erfolgt keine Än¬ 
derung. 

gibt alte 'banknum' zurück 


XBIOS 83 (nur TT) 

WORD EsetColor(WORD colornum, WORD color) 

colornum, wie XBIOS 7 nur komplette 256 Farben 
color , %XXXX rrrr gggg bbbb 

wenn negativ - keine Änderung 

gibt alten Wert zurück. 
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XBIOS 84 (nur TT) 

VOID EsetPalette(WORD colorNum, Word count, LONG ‘palette) 

colorNum , Nummer des Startregisters 
count , Menge der zu lesenden Register 
‘palette , Zeiger auf ein Feld mit 4 Bit RGB Werten 
%XXXX rrrr gggg bbbb 

kopiert die Farbwerte im mit ’*palette’ angegebenen Feld in die 
Farbregister 


XBIOS 85 (nur TT) 

VOID EgetPalette(WORD colorNum, WORD cont, LONG ‘palette) 

colorNum , Nummer des Startregisters 
count , Menge der zu lesenden Register 
‘palette , Zeiger auf ein leeres Feld 

schreibt Inhalt der Paletteregister in den angegebenen 
Speicherbereich. 


XBIOS 86 (nur TT) 

WORD EsetGrey(WORD switch) 

switch, wenn >0 schaltet auf Hypermono 

wenn =0 schaltet auf 4096 Farbpalette zurück 
wenn <0 Register wird nicht geändert 

siehe auch $ffff8262 shift_tt Kapitel B.1.1.1 

gibt alten Wert zurück. 
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XBIOS 87 (nur TT) 

WORD EsetSmear(WORD switch) 

switch, wenn >0 schaltet in den Sample and Hold Modus 
wenn =0 schaltet zurück in den "normalen Modus“ 
wenn <0 Register wird nicht verändert 

siehe auch $ffff8262 shift_tt Kapitel B.1.1.1 

gibt alten Wert zurück. 


XBIOS 88 (nur FALCON) 

WORD Vsetmode(WORD modecode) 
modecode, %XXXXXXXFSOPV8NNN 

NNN 0=1 Bits per Pixel, Mono/Duochrome 

1 = 2 Bits per Pixel, 4 Farben 

2 = 4 Bits per Pixel, 16 Farben 

3=8 Bits per Pixel, 256 Farben 

4 = 16 Bits per Pixel, 65536 Farben 

8 wenn gesetzt 80 Zeichen pro Zeile, sonst 40 
V wenn gesetzt VGA Monitor, sonst Fernseher 
P wenn gesetzt PAL 50 HZ, sonst NTSC 60 HZ 
O wenn gesetzt X,Y Auflösung mal 1.2 
S wenn gesetzt ST kompatible Auflösung/Palette etc. 

F Interlace an, wenn P gesetzt 
X reserviert für zukünftige Erweiterungen 

Nicht unterstützt wird das Mischen von: 

80 Zeichen pro Zeile also 640 Spalten und VGA bei 16 Bit p. P. 
40 Zeichen pro Zeile also 320 Spalten und 1 Bit p. P. 
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wenn modecode=-1 keine Änderung der Auflösung, gibt alte Auflö¬ 
sung zurück 

ATARI empfielt ’Setscreen’ zum Ändern der Auflösung, da ’Vset- 
mode’ das VDI nicht umschaltet. 


XBIOS 89 (nur FALCON) 

WORD mon_type() 

Gibt zurück, welcher Monitor am Falcon angeschlossen wurde. 

0 = ST Monochrome Monitor 

1 = ST Färb Monitor 

2 = VGA Monitor 

3 = Fernseher 


XBIOS 90 (nur FALCON) 

VOID VsetSync(WORD extemal) 
external, %XXXXXXXX XXXXXhvc 
wenn gesetzt 

h = externe horizontale Syncronisation 
v = externe vertikale Syncronisation 
c = externe Pixelfrequenz 

Wird zur Synchronisation mit Genlocks u. Videobandmaschinen 
etc. verwendet. 
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XBIOS 91 (nur FALCON) 

LONG Vgetsize(WORD mode) 
mode, siehe XBIOS 88 

gibt den Speicherbedarf der in mode angegeben Auflösung zurück 


XBIOS 93 (nur FALCON) 

VOID Vset RGB (WORD index, WORD count, LONG *array) 

index , Farbregister Start 

count , Menge der zu übertragenen Register 

*array , n Wörter mit dem Paletteninhalt "Xrgb" 

X = unbenutzt %XXXXXXXX 

r = ein Byte Intensität rot %rrrrrrXX g = ein Byte Intensität 
grün%ggggggXX 

b = ein Byte Intensität blau %bbbbbbXX 

Überträgt Palette aus dem Speicher in die Palettenregister. 


XBIOS 94 (nur FALCON) 

VOID VgetRGB(WORD index, WORD count, LONG *array) 

index , Farbregister Start 

count , Menge der zu übertragenen Register 

*array , leeres Feld 

überträgt Palette aus Palettenregister in den Speicher. 
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XBIOS 150 (nurFALCON) 

VOID VsetMask(WORD andmask, WORD ormask) 

andmask, Maske für AND Verknüpfung (default $FFFF) 
ormask , Maske für OR Verknüpfung (default $0000) 

Darf nur in "True" - Color - Modi verwendet werden ! 

Diese Masken werden mit den durch vs_color (VDI) gesetzten 
Farben verknüpft um die Möglichkeit zu bieten, auch über das VDI 
gesetzte Bildpunkte bei der Benutzung eines Genlocks durchsichtig 
erscheinen zu lassen. 


1.2 Hardware Scrolling auf dem STE 

Ein großes Manko der Atari ST Computer bei der Spieleprogram¬ 
mierung ist wohl das nur sehr umständlich zu realisierende hori¬ 
zontale Scrolling. Scrolling, für alle die dies bis jetzt immer noch 
nicht wissen, ist das Hin und Her-Bewegen des Hintergrundes 
bzw. der Spielfläche. Das beste Beispiel für butterweiches 8 Wege 
Scrolling ist der Gauntlet Automat von Atari, aber auch viele Spie¬ 
le/Demo Programmierer haben schon recht gutes Scrolling auf ei¬ 
nem Standard ST zustande gebracht. Da aber das Bewegen riesi¬ 
ger Bildschrimblöcke entweder ’ne Menge Speicher oder ’ne Menge 
Rechenzeit (nicht jeder hat einen 68030 oder einen Blitter) 
schluckt, hat Atari den Videoprozessor in den STE’s so modifiziert, 
daß man sich einfach einen großen Bildschirm im Speicher anlegt, 
in dem dann der auf dem Monitor angezeigte Bildschirm nur einen 
Ausschnitt darstellt, der nach Belieben in dem im Speicher befindli¬ 
chen hin und her geschoben werden kann. Dies geschiet durch das 
Verändern einiger weniger Register; der Aufwand hierfür fällt dann 
effektiv nicht mehr ins Gewicht. 
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1.2.1 Der VBL (Vertikal Blank) Interrupt 
Start der Interrupts 



Nun, wird mancher sich fragen, was hat den ein Interupt mit Scrol¬ 
ling zu tun ? 

Es ist im Prinzip derselbe Grund wie beim Bewegen von Sprites, 
denn die Bildausgabe muß eben mit dem Bildaufbau synchronisiert 
werden, und da die Register, die zur Vereinfachung des Scrollings 
dazu gekommen sind, sofort reagieren, dürfen sie erst vor dem 
Aufbau des Monitorbilds beschrieben werden. Genau an diesem 
Punkt (nach der letzten dargestellten Zeile) erzeugt eben die Vi¬ 
deohardware des Atari einen Interrupt .Bedingt durch den 68000er, 
der in allen ST’s zu finden ist, gehen alle Programmierer davon 
aus, daß die Vektoradresse zum VBL auf $70 befindet. Bei den 
neueren Prozessoren 68010/20/30/40/60 läßt sich jedoch die Vek¬ 
tortabelle, in der sich der VBL befindet, beliebig im RAM verschie¬ 
ben. Es ist jedoch nicht zu erwarten (allein von der Sytemarchitek- 
tur), daß sich die Vektortabelle in kommenden TOS-Versionen ver¬ 
schieben wird. Jedoch ist es möglich, mit ’setexec’ (BIOS 5) die 
Vektorenbetriebssystemkonform zu ändern. 

Nun gibt es mehrere Methoden, sich in den VBL Interrupt zu “hän¬ 
gen". Eine saubere Methode ist es, die Adresse der eigene Routi¬ 
ne, die während des VBL aufgerufen werden soll, in eine Liste von 
anderen Adressen zu schreiben. Diese Liste wird automatisch von 
der VBL Routine des Betriebssystems ausgeführt. Die Systemva¬ 
riable ’_vblqueue’ an der Adresse $454 zeigt auf diese Liste . An 
der Adresse $454 ’nvbls’ ist dann die Größe der Liste eingetragen 


161 





Spiele selbst programmieren 


(normalerweise eine acht). Sollten alle Einträge belegt (also <>0) 
sein, sollte man eine größere Liste im RAM anlegen und die alten 
Adressen in die neue Liste kopieren. Nicht vergessen sollte man 
die Größe der neuen Liste in ’nvbls’ einzutragen. Allerdings ist dies 
selten nötig, da die Liste nach dem Booten meistens nur ein Eintrag 
vom Betriebssystem hat, das seine Zeichenroutine für die Maus 
immer (!) an die erste Stelle einträgt. Falls man sich also aus dem 
'AUTO' Ordner einträgt (denn dann ist der erste Eintrag noch nicht 
belegt), sollte man sich nie an die erste Stelle eintragen, denn 
sonst wird man gnadenlos vom GEM überschrieben. 

Eine andere Möglichkeit, sich in den VBL zu "hängen“, ist sich di¬ 
rekt in die Adresse $70 einzutragen, also dem Vektor, in dem das 
Betriebssystem "hängt" und nach Beendigung der eigenen Routine 
wieder das Betriebssystem anzuspringen. Das hat wesentliche 
Vorteile! Denn man kommt als erster zum Zug, was sehr wichtig 
ist, wenn man viel während des VBL’s zu erledigen hat und jede 
Verzögerung auf dem Bildschirm zu sehen wäre. Auch ist diese 
Methode mit geringem Aufwand zu realisieren. Wenn es sich bei 
dem Programm, das man in den Bildrücklauf installiert, um ein re¬ 
sidentes Programm handelt oder um ein Programm, das in einem 
Fenster auf dem Desktop läuft (also man sich möglicherweise nicht 
allein im Rechner befindet), sollte man das XBRA Verfahren benut¬ 
zen, da dieses Verfahren es möglich macht, sich gegebenfalls wie¬ 
der aus dem Vektor zu entfernen oder zumindest sich nicht ein 
zweites Mal zu installieren. Der VBL-Interrupt wird immer dann 
aufgerufen, wenn sich der Elektronenstrahl des Monitors auf dem 
Weg vom unteren Bildschirmrand zum oberen befindet, also 50/60 
oder ca. 71 mal pro Sekunde, es ist in dieser Zeit möglich, alle 
Farbregister zu verändern oder eine begrenzte (begrenzt durch die 
zur Verfügung stehende Rechenzeit) Menge von Sprites auf den 
Bildschirm zu bringen oder eben die Register zum Hardwarescrol¬ 
ling zu setzen. 
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1.2.2 Wie geht nun aber das Hardware Scrolling ? 

Nun, Atari hat dem Shifter des STE/F030 einige neue Register 
spendiert, die das Scrolling fast zum Kinderspiel machen. 

1.2.2.1 Vertikales Scrolling (auch auf dem TT möglich) 

Um vertikales Scrolling zu vereinfachen, wurde dem Programmie¬ 
rer die Möglichkeit gegeben, mit Hilfe eines Low - Bytes ($ff 8209) 
die Bildschirmadresse wortweise im Speicher zu verschieben. Das 
ist eigentlich schon "die halbe Miete“, denn dann braucht man nur 
zwei Bildschirme hintereinander in den Speicher zu laden und die 
Bildschirmadresse ganz langsam im Speicher herunter zu schie¬ 
ben. (auf der beiliegenden Diskette befindet sich im Programm 
’kapitell TOS’ das File ’stescroll.tos’, das horizontales und vertika¬ 
les Hardwarescrolling und gescrollte Teilbilder (Split Screen) 
zeigt.) Nun muß dies nicht unbedingt durch einen direkten Zugriff 
auf die Adresse geschehen! Es reicht vollkommen, die Betriebssy¬ 
stem-Routine ’Setscreen’ (Xbios 5) zu benutzen, da diese an die 
neue Hardware angepaßt ist. 

1.2.2.2 Horizontales Scrolling 

Vertikales Scrollen läßt sich noch leicht ohne zusätzliche Hardware 
realisieren (auch wenn es mit viel leichter geht), jedoch das hori¬ 
zontale Scrolling ist auf einem normalen ST Sysiphus Arbeit. Daher 
gibt es für diesen Zweck zwei neue Register. Zum einen das 'Pixel 
Offset’ Register, das den Videoprozessor dazu bewegen kann bis 
zu 15 Pixel (also fast das erste Wort) am Anfang der Zeile zu 
schlucken. Allerding würde bei einem Inhalt dieses Registers <> 0 
die Zeile um den Inhalt des Registers länger werden. Um das aus¬ 
zugleichen, gibt es das ’Zeilenbreite’-Register, das den Prozessor 
dazu bringt, am Ende jeder Zeile bis zu 16 Worte im Bildschirm¬ 
speicher zu überspringen. Um z.B. zwei Monochrom-Bilder neben¬ 
einander auf dem Bildschirm horizontal scrollen zu können, muß 
man das ’linewid’ Register auf 39 setzen, für die mittlere Auflösung 
(und entsprechenden 4 vierfarbigen Bildern) 78 Worte und für die 
niedrige Auflösung 76 Worte. Eine leicht zu merkende Formel ist: 
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I = länge einer Zeile in Worten 

mittlere & niedrige ST Auflösung je 80 Worte 
hohe ST Auflösung 40 Worte 
Falcon, verschieden! 

b = Menge der zu scrollenden Bilder nebeneinander (in einer Reihe) 


w = Worte pro 16 Pixel 

monocrome Auflösung 

4 -farbige Auflösung 

16 -farbige Auflösung 

256 -farbige Auflösung 


1 Wort 

2 Worte 
4 Worte 
8 Worte 


’linewid’ = l*(b-1)-w 


Achtung ! ’linewid’ kann nicht größer als 255 werden, da das Regi¬ 
ster nur ein Byte breit ist. 

Aber nun mehr zum Praktischen ! 

Zuerst kopiere ich mir die zu scrollenden Bilder Zeile für Zeile hin¬ 
tereinander, z.B. bei zwei Bildern 

erstes Bild erste Zeile / zweites Bild erste Zeile 

erstes Bild zweite Zeile / zweites Bild zweite Zeile 


erstes Bild nte Zeile/ zweites Bild nte Zeile 

Dann berechne ich mir den Wert für das ’linewid’ Registers nach 
der oben auf geführten Formel, setze das ’linewid’ Register und auf 
dem Bildschirm erscheint (falls sich die Bilder im Bildschirmspei¬ 
cher befinden) das erste Bild. Um dann zu scrollen, erhöhe ich das 
’pixel offset’ Register bis es den Wert 15 ereicht, dann setze ich 
dieses Register wieder auf Null, dann wiederum erhöhe ich die 
Bildschirmadresse um ein Wort und beginne von vom. Wenn man 
diesen Vorgang nicht mit dem Bildrücklauf synchronisiert, sieht 
man das Umschalten der Register auf dem Monitor. Um das zu 
vermeiden, habe ich eine Routine geschrieben (als GFA-Basic-Inli- 
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ne), die diesen Zweck erfüllt. Um zu vermeiden, daß das Setzen 
der Register (wenn sich viele Programme in den Interrupt hängen, 
kann das passieren) zu spät erfolgt, hängt sich mein Programm als 
allererstes in den VBL Vektor, und springt dann die Routine an, die 
zuvor im Vertical Blank Interrupt (VBL) hing. Da der Video Prozes¬ 
sor den Inhalt der Video Basis Register möglicherweise schon in 
die Adress Counter übertragen hat (was bei jedem 16 Pixel ein 
leichtes Flackern bedeuten könnte), beschreiben wir an dieser 
Stelle auch gleich die Address Counter Register mit der Bild¬ 
schirmadresse mit Offset (low byte) für’s horizontale Scrolling, da 
der STE-Video-Shifter sofort auf das Beschreiben dieser Register 
reagiert. Viel Spaß! 


1.2.3 Virtuelle Bildschirme 

Es gibt mehrere Möglichkeiten, virtuelle Bildschirme zu realisieren. 
Allen zu Grunde liegt eine logische Erweiterung der Bildschirmauf¬ 
lösung, ohne physikalisch eine solche darstellen zu können. Im 
Klartext z.B. die Simulation eines 1280*960 Punkte großen Schirms 
(also TT hoch) auf einem SM 124 (also ST hoch mit 640*400 Punk¬ 
ten). 

Diese Simulation ist zum einen ein Hardware-Problem, da man ein 
System finden muß, um den kleinen physikalischen Bildschirm im 
größeren logischen Bildschirm zu verschieben. Nehmen wir an, bei 
dem Rechner handele es sich um einen STE, dann ist das Problem 
mit Hilfe des Hardwarescrollings (siehe 1.2.1.2) zu lösen. 

Dann bleibt immer noch das Problem, der Software beizubringen, 
mit einem größeren Bildschirm zu arbeiten. Die wohl "kompatibel¬ 
ste“ Möglichkeit, mit AES & VDI die neue Auflösung zu nutzen, ist, 
einen eigenen GDOS Bildschirmtreiber zu schreiben. Nun, das ist 
erstens sehr aufwendig und zweitens wird diese Technik von kei¬ 
nem mir bekannten Programm zum Erzeugen virtueller Auflösun¬ 
gen genutzt. Wer nur dem internen Gerätetreiber des VDI beibrin- 
gen möchte, daß sich "plötzlich" die Auflösung geändert hat, kann 
das mit Hilfe der sogenannten negativen Line A Variablen tun . Die 
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negativen Line A Variablen sind so etwas wie die lokalen Variablen 
des VDI. Beim Ändern dieser Variablen paßt man damit automa¬ 
tisch das VDI an. Allerdings hat davon das AES (der Teil des Be¬ 
triebssystems, der für die Ausgabe von Menüs, Fenstern, Dialog¬ 
boxen etc. zuständig ist) noch gar keine Ahnung, um das zu än¬ 
dern, müßte man (oder auch Frau) das Programm in den Auto Ord¬ 
ner plazieren, also vor der Initialisierung von VDI und AES. Von 
dort ändert es dann die negativen Line A Variablen und setzt nach 
dem Öffnen der Workstation die richtigen Auflösungswerte in 
work_out(0) und work_out(1) ein. Aber die Anpassung von AES ist 
für den Spieleprogrammierer nicht allzu wichtig, da er es nur in den 
seltensten Fällen benutzt (z.B. bei Grafik Adventures oder Brett¬ 
spielen) und dann meistens keinen virtuellen Bildschirm benötigt. 
Es ist aber gelegentlich nicht zu verachten, auf große zu scrollende 
Bilder der Einfachheit halber mit dem VDI zuzugreifen (z.B. für ein 
Zeichenprogramm oder eine Simulation). 


1.3 Eine Auswahl von fast 4096 (3375) Farben auf eine normalen ST 

Bei der Konvertierung vom Amiga auf den Atari haben die Pro¬ 
grammierer oft das Problem der zu geringen Farbauswahl. Sie 
würden zwar mit den 16 Farben auskommen (indem sie mehrmals 
umschalten) aber die Palette der "alten" ST’s ist mit 512 Farben 
einfach zu klein. Auch bei digitalisierten Bildern tritt häufig das Pro¬ 
blem auf, daß man gerne mehr als 8 Graustufen auf dem Schirm 
darstellen möchte, da das viel hübscher ist als z.B. 16 Rot-oder 
Grün-Stufen. 

Ich stelle hiermit eine Lösung für diese und ähnliche Probleme vor. 
Ich schreibe einfach ein Programm, das bei jedem VBL alle 16 Fra- 
bregister des ST wechselt, und dabei an den Stellen wo man eine 
Farbe erzeugen möchte, die sich nicht in den 512 Farben des ST 
befindet, wechselt man bei jedem VBL den Inhalt des Palettenregi¬ 
sters mit den Farben, die gerade noch darstellbar sind und oberhalb 
bzw. unterhalb der Wunschfarbe liegen. Dabei wird zwar ein leich¬ 
tes Flackern sichtbar, allerdings nur bei größeren Flächen. 
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Wie funktioniert es genau ? 

Also der ATARI ST kann normalerweise 16 aus 512 Farben dar¬ 
stellen. Wobei jede der 16 Farben ein Palettenregister besitzt. Die¬ 
se Palettenregister besteht aus 4 * 4 Bit 

R=rot G=grün B=blau U=unbenutzt 

Palettenregister: (16 Bit also i Wort) 

UUUU URRR UGGG UBBB 

Wie man sieht, sind in den niederwertigen 12 Bit die RGB Informa¬ 
tionen enthalten, wobei das 4. Bit pro Nible (4 Bit Block) bei ST’s 
(nicht STE/TT) unbenutzt ist. 

Das ergibt 3 Grundfarben mit je 3 Bit also 8 Stufen ! 
das ergibt 8 hoch 3 = 512 Farben 

wenn man jedoch die Trägheit des Auges ausnützt und durch 
schnelles Wechseln der Farben für je eine Grundfarbe - RGB eine 
Zwischenstufe erzeugt. 

Also etwa so: 

z.B. ROT 


01 234567 Farbstufen 


0 1 2 3 4 5 6 1. Farbe 

1 2 3 4 5 6 7 2. Farbe 


I I I I I I I I I I I I I I I effektive 

1 2 3 4 5 6 7 8 9 1011 12 13 14 15 Farbstufen 
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Mir ist bisher nur ein Spiel bekannt, das diese Technik benutzt um 
mehr Farbabstufungen darstellen zu können, und zwar First Samu¬ 
rai von Imageworks. Auch wurde in der Ausgabe CT 6/92 ein Pro¬ 
gramm vorgestellt, das mit dem gleichen Verfahren die ST-Hoch 
Auflösung mit einem Grauton versieht, allerdings werden in diesem 
Fall zwei Bildschirmspeicher benutzt, die durch beschreiben der 
Video Basis Register immer umgeschaltet werden. Auch in ande¬ 
ren Auflösungen sind mit dieser Technik erstaunliche Effekte mög¬ 
lich, das Flackern läßt sich leider nicht vermeiden, nur durch eine 
60 Hz Umschaltung erträglicher machen. Unter den Programmen 
zum Thema Bildformate befindet sich ein komplett dokumentiertes 
Listing, das IFFs Bilder lädt und auf einem ST die 4096 Farben des 
STE mit der von mir oben vorgestellten Technik simuliert. 


1.4 Fullscreen und Syncscroller Programmierung 

(nur bei ST/STE und in Farbauflösungen möglich) 

In Demos und mittlerweile auch in einigen Spielen kann man 
Syncscroller (meist nur in Demos) und geöffnete Bildschirmränder 
bewundern (z.B. die Anfangsdemo zu Turrican II). Wenn man sich 
die Register des Ur-ST’s anschaut, sind solche Effeckte nicht zu 
erklären, da keines dieser Register auch nur entfernt etwas mit 
Scrolling oder den Rändern des Bildschirms zu tun hat. 

In den Scrolltexten einiger Demos liest man von einem gewissen 
"Alyssa", der als erster Programmierer den ST dazu gebracht hat 
Pixel, außerhalb seiner Bildbegrenzungen darzustellen. Alyssa öff¬ 
nete den unteren Rand. Die erste Demo, die unteren Rand benutz¬ 
te, müßte die "TEX and Alyssa Super - Neo Demo“ gewesen sein, 
die im unteren Rand eine Laufschrift und ein bißchen Animation 
zeigt, etwas Musik spielt und Bilder im ’NEOCROME’ Format in 
den oberen Teil des Bildschimspeichers lädt. 
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Danach folgte die ’B.I.G. D.E.M.O’ (auch von TEX - also The EX- 
ceptions). Nachdem die Demo-Programmierer noch den oberen 
Rand öffneten, folgte auch bald die "Eröffnung" des rechten und lin¬ 
ken Rands und nach einiger Zeit auch ein (Amiga-like) Fullscreen, 
der wohl zu allererst in dem 'LEVEL 16’ Screen in der Union Demo 
zu sehen war, am unteren Rand des "main menue" Screen der De¬ 
mo konnte man auch schon sogenanntes "Syncscrolling" bewun¬ 
dern. 


1.4.1 Geöffnete Bildschirmränder 

Das Heranschaffen, Darstellen und Syncronisieren von Videodaten 
wird im ATARI von drei Prozessoren übernommen. Zum einem der 
GLUE, der außer seiner vielen anderen Tätigkeiten, das HSYNC, 
VSYNC und das DE (Display Enable) Signal erzeugt. HSYNC und 
VSYNC sind für die Syncronisation des Monitors zuständig und 
das DE Signal, das auch an den Eingang vom Timer B geht, wird 
dann gegeben , wenn eine Zeile geschrieben wird (aber dazu kom¬ 
me ich noch im Kapitel über den Timer), und genau dieses Signal 
ist wichtig. In der MMU liegen die Video - Adress Counter; dieser 
Chip liefert die darzustellenden Adressen an den Shifter. Der Shif- 
ter wiederum erzeugt die RGB Signale für das Bild aus den Wer¬ 
ten, die in seinen Palettenregister stehen. An den Rändern liefert 
der GLUE kein DE Signal, das den Shifter dazu bringt, nur noch 
Hintergrundfarbe (Palettenregister 0) dazustellen. Wenn man aller¬ 
dings die Register des GLUE im richtigen Augenblick mit den rich¬ 
tigen Werten beschreibt, vergißt er das Löschen des Signals und 
der Shifter dekodiert munter Speicher zu RGB Signalen, was mehr 
Bild auf dem Monitor bedeutet. Aber nur, da die MMU, beim Fehlen 
des Display Enable, weiterhin Informationen an den Shifter liefert. 
Das Problem dabei ist nun die Toleranzen der drei Chips, je nach 
dem aus welcher Serie sie stammen kann man sie (per Software) 
zu mehr oder weniger Zeilen und Pixel überreden. Auch treten zwi¬ 
schen den ST und STE Chips größere Toleranzen auf. 

Das ganze ist eben eine undokumentierte Eigenschaft der Baustei¬ 
ne, für die Atari nicht garantiert. 
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1.4.1.1 Das Öffnen des unteren Randes 

(Was wohl die leichteste Disziplin ist!) 

Im Prinzip muß man nur bis zur Zeile 199 warten, dann mal kurz 
von 50 auf 60 Hz schalten, etwas warten und dann wieder von 60 
auf 50 Hz schalten, und schon hat man etwa 45 Zeilen mehr am 
unteren Bildschirmrand. Das komplizierteste dürfte das Warten auf 
die zweihundertste Zeile sein ! 

Hier der Ausschnitt eines Listings, zum realisieren einer relativ 
sauberen Umschaltung: 

Routine wird vom Timer B an Zeile 198 gestartet, der im VBL -In¬ 
terrupt darauf programmiert wird. 

Timer B steht im ’EVENT COUNT’ Modus (siehe Kapitel über Ti¬ 
mer Programmierung). 

timerb: 

move.l DO,-(SP) 
warten: 

cmpi.b #180,tbdr 
bne.s warten 

andi.b #11111101 .syncmode 


;wird nur in einem Fall benötigt 
;Timer B zählt von Zeile 190 abwärts 

;Wartet bis Timer B Data Register auf 
;180 ist, denn 190-180=10 ! also 
;befindet sich der Rechner an der 
;200sten Zeile 
;auf 60Hz schalten 


Hier kommen jetzt zwei Möglichkeiten, auf den richtigen Moment 
zum Umschalten zu warten: 


********************************************* 
move.w #1,D0 

pause: nop ;etwas 

dbra.s DO,pause ;warten 

********************************************* 
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oder besser noch (da kompatibler zu 68010 oder Beschleunigern) 


********************************************* 

rept 14 ;macht 14 NOP’s 

nop 

endr 

***★*★★★****★★**★*******★★★********★*★★★★***★ 


ori.b #2,syncmode 

move.b #0,tbcr 
bclr #0,isra 

move.l (sp)+,d0 
rte 


;wieder 50Hz 
;Timeraus 

;lntempt beendet, Intempt in 
;service Bit löschen !!! 

;d0 wieder zurück 


Natürlich wäre auch ein ’MOVE’ zum Syncmode Register möglich, 
würde aber auf dem TT zu einem schwarzen Bildschirm führen, da 
auf dem TT das Bit zur externen Syncronisation invertiert ist!!! 

Diese Routine funktioniert nur auf 8 MHZ oder >16MHZ ohne Ca¬ 
che (nur die Routine mit den NOP’s). Auf dem TT bleibt die 50/60 
Hz Umschaltung ohne Wirkung, da bei diesem Gerät das dazuge¬ 
hörige Bit des ’Syncmode’ Registers gar nicht existiert. 


1.4.1.2 Das öffnen des oberen Randes 

Etwas vorab, der HBL ! 

Der HBL (Horizontal BLank) wird theoretisch nach jeder Zeile aus¬ 
gelöst, allerdings ist die Interruptmaske beim ST so hoch gesetzt, 
das der HBL nicht ausgeführt wird. Falls er doch ausgeführt wird, 
ab Blitter TOS nach jedem Programmstart, setzt die Routine, auf 
die der HBL Vektor zeigt, die Interuptmaske wieder so hoch, daß 
kein HBL mehr auftritt. Er liegt an der Adresse $68 (Offset zum 
Anfang der Vektortabelle - auf dem ST mit 68000 liegt diese ab 
Adresse 0 im Speicher $68 ist hier eine absolute Adresse) und ist 
ein Autovektorinterrupt, das heißt, es wird kein Interruptcontroller 
(z.B. MFP im ATARI) benötigt, um den Interrupt auszulösen. 
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Laut einiger Demo-Programmierer hängt die Menge der zu öffnen¬ 
den Zeilen des oberen Bildschirmrandes von der im Gerät verwen¬ 
deten MMU (Memory Management Unit), die die Video Adress 
Counter enthält, ab. Aber im Prinzip kann es dem Demo-Program¬ 
mierer egal sein, welcher Baustein für das veränderte Verhalten 
verantwortlich ist, wenn er weiß, wie er damit umzugehen hat. Je 
nach MMU Typ scheint es auf ST/STE möglich zu sein, etwa 13 
bzw. 29 Zeilen mehr oberhalb des normalen vom ST/STE darge¬ 
stellten Bildausschnitt, darzustellen. Nun, dazu muß man an dieser 
Stelle wieder eine 50/60 Hz Umschaltung, eine kleine Pause und 
eine 60/50 Hz Umschaltung vornehmen. Da an dieser Stelle noch 
vom GLUE noch kein DE (Display Enable) Signal kommt, ist es 
nicht möglich, den Event Count Mode des Timer B zum Auffinden 
dieser Stelle zu nutzen. Es gibt meines Wissens zwei Möglichkei¬ 
ten, die Zeile (echte Bilschirmzeile) zu finden, an der man um¬ 
schalten muß. Zum einen kann man im VBL alle Interrupts außer 
dem HBL ($68 wird normalenweise nicht benutzt und hat eine sehr 
niedrige Priorität) sperren und die HBL’s zählen. Nach etwa 33 
HBL's hält man mit STOP #$2300 den Prozessor an, dieser wartet 
dann bis zum nächsten HBL. Dann noch etwa 86 nop’s warten, auf 
60 Hz schalten, wiederum ca. 14-17 nops und wieder auf 50 Hz 
schalten. Eigentlich müßte der obere Rand sich dann öffnen. Na¬ 
türlich ist auch die Kombination vom geöffneten oberen und unteren 
Rand möglich. Die zweite Methode setzt einen Timer in der letzten 
Zeile, und wartet bis die richtige Stelle ereicht ist; natürlich müssen 
alle anderen Interrupts (die stören könnten) währendessen ausge¬ 
schaltet sein. 


1.4.1.3 Das Öffnen aller Ränder 

Ich will es kurz machen, denn die Sache ist zwar hübsch anzu¬ 
schauen - aber eine “elendige Taktzyklenzählerei". Man sucht sich 
nach der oben genannten Methode (Öffnen des oberen Bilds¬ 
schirmrands) den Anfang des oberen, geöffneten Bildschirmrands, 
öffnet ihn und syncronisiert den Prozessor mit dem Aufbau einer 
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Zeile, setzt an den richtigen Stellen in den Zeilen eine 50/60 Hz 
bzw. 50/71 Hz Umschaltung vor, und öffnet damit den linken und 
rechten Rand. 

Es ist fast unmöglich, zum Öffnen aller Ränder zusätzlich bewegte 
Grafik und/oder digitalisierten (YAMAHA) Sound zu bringen. Das 
einige Demoprogrammierer das doch geschafft haben, liegt an der 
Möglichkeit, statt den NOP’s andere Prozessorbefehle zur Bild¬ 
synchronisation zu nutzen und somit den Programmteil für Grafik 
und Sound, in die Routine zum Öffnen der Ränder, quasi ''hineinzu¬ 
weben''. Ein mächtig kompliziertes Unterfangen ! 


1.4.2 Der "sogenannte" Syncscroller 

Eigentlich wird dabei nur das fehlende Low Byte der Video Basis 
Register im ST simuliert. Bei STE/TT existiert so ein Register, eine 
Simulation ergibt somit bei diesen Geräten nur wenig Sinn. 

Wenn man die Techniken zum Öffnen der Bildschirmränder ver¬ 
standen hat, ist die Sache mit dem Syncscrolling relativ einfach zu 
realisieren (man muß eben darauf kommen !). Im Prinzip basiert 
der Syncscroller auf der Eigenschaft des Bildschirmspeichers grö¬ 
ßer zu werden, wenn man mehr Pixel in einer Zeile darstellt. Das 
klingt eigentlich recht banal, so muß man nur die Ränder von eini¬ 
gen Zeilen öffnen (mal den linken und mal den rechten Rand) und 
schon verschiebt sich der Bildschirmspeicher. Am unauffälligsten 
ist es, die geöffneten Zeilen in den oberen Rand (den muß man na¬ 
türlich vorher öffnen) zu plazieren, dann schaltet man im VBL alle 
Farbregister dunkel und setzt sie erst nach der Öffnung der Ränder 
wieder auf sichtbare Farbwerte und schon kann keiner sehen, daß 
irgendwelche Manipulationen im oberen Rand vorgenommen wor¬ 
den sind. 
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1.5 Die VIDEO - Hardwareregister im Falcon030 

... oder was eigentlich keiner wissen oder benutzen darf 
Vielen Dank an Torsten Lang für seine hilfreichen Tips zu diesem Thema! 

Achtung ! **** UNDOKUMENTIERT **** 

Benutzung strengstens verboten !!! 

Ich übernehme keine Gewähr auf Richtigkeit der hier angegebenen 
Daten. Die hier angegebenen Register habe ich durch Versuchen 
und teilw. durch Disassemblieren des Betriebssystems gefunden. 
ATARI hat keines dieser Register dokumentiert (wahrscheinlich 
wird dies auch nicht passieren) und hat die neuen Register im F030 
in manchen Fällen so ungünstig positioniert, daß es in vielen Fällen 
zu Problemen mit vorhandener Software, vorrangig Spielen/De¬ 
mos, kommt, die trotz der Möglichkeit den F030, auf ein 8 MHz Ti¬ 
ming zu schalten, ihren Dienst verweigern. Schade, da hätte mehr 
Rücksicht auf vorhandene Applikationen, mit relativ geringem Auf¬ 
wand betrieben werden können. Trotz alledem ist der F030 eine 
faszinierende Maschine, leider hat es ATARI verpaßt, der doch 
recht ausgereiften VIDEO - Hardware des F030 ebenso mächtige 
Betriebssystem-Funktionen zur Verfügung zu stellen; aus diesem 
Grund und für die Programmierer systemnaher Software habe ich 
mich entschlossen, die Video-Hardware-Register des F030 (vor¬ 
läufig) zu dokumentieren. 

Wer sich die neuen Register des F030 anschaut, wird bei der Lei¬ 
stungsfähigkeit an Video-Prozessoren wie den Tseng ET4000 oder 
den ARABELLA Video Chip des Archimedes erinnert. 

Man verzeihe mir bitte die Ungenauigkeiten, aber es ist nicht immer 
einfach, die Funktion eines Registers durch seine Wirkung zu er¬ 
kennen. 
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Falcon Shift-Mode-Register 

$ffff8266 W %XXXXXXXT XVHPXBBB 

T = True Color / 65536 Farben Bit 
V = externe vertikale Synchronisation 
H = externe horizontale Synchronisation 
P = 256 Farben 

BBB = Bank zu 16 Farben, die in 16er Schritten aus der 256 
Farbpalette "CLUT" gewählt werden kann. 

Wenn weder T noch ’P’ gesetzt ist, befindet sich der Rechner im 
16 Färb Modus, 

Das "256 Farben" Bit funktioniert nur, wenn das "True Color" Bit 
gelöscht ist. 

In diesen Modi gilt die Falcon 18 Bit-Palette 


Horizontale Position 

$ffff828c W %nnnnnnnn nnnnIPPP RW h_pos 
I = Interlacean 

PPP = Verschieben des Bildbereichs von links nach rechts 
Wirkung: 

Damit läßt sich der dargestellte Bildbereich nach links oder rechts 
schieben, so weit der Monitor es schafft, das Bild zu synchronisie¬ 
ren. Wenn das T Bit gesetzt ist, ergibt sich die Interlace Darstel¬ 
lung. 
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Umstellen auf entsprechenden Monitor Typ 

PAUNTSC/VGA 

$ffff82c0 W %nnnnnnnP nMnnnVnn RW mon_typ 
Wenn Bit gesetzt 

P = PAL flag (z.B. Deutsches Fernsehen) 

N = NTSC flag (Fernsehnorm in den USA) 

M = Monocrome flag (z.B. SM 124/144 etc) 

Beim gleichzeitigen Setzen mehrerer Bits entstehen interessante 
Effekte! 

Zeilenwiederholfrequenz 

$ffff8282 W %XXXXXXXn nnnnnnnn RW h.cycle 

Horizontal Blank rechts (nicht in ST hoch 71Hz) 

$ffff8284 W %XXXXXXXn nnnnnnnn RW sr_hblank 

Mit diesem Register läßt sich einstellen, wann in der Zeile (ab der 
Mitte bis an den rechten Rand) der Videochip dunkel schaltet. 

Horizontal Blank links (nicht in st hoch 71Hz) 

$ffff8286 W %XXXXXXXn nnnnnnnn RW sl_hblank 
Wie Register zuvor, nur von der Mitte zum linken Rand. 
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Linker Rand 

$ffff8288 W %XXXXXXXn nnnnnnnn RW 

Rechter Rand 

$ffff828A W %XXXXXXn nnnnnnnn RW 

Horizontal Sync Start 

$ffff828c W %nnnnnnnn nnnnnnnn RW 

Bildwiederholfrequenz 

$ffff82a2 W %XXXXnnnn nnnnnnnl RW 

l=lnterlace, wenn gesetzt, Interlace aus 

Vertikal Blank unten 

$ffff82a4 W %XXXXXXXn nnnnnnnn RW 

Vertikal Blank oben 

$ffff82a6 W %XXXXXXXn nnnnnnnn RW 


r_border 


Lborder 


h_sync_start 


v_cycle 


h_dis_start 


h_dis_end 
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Oberer Rand 

$ffff82a8 W %XXXXXnnn nnnnnnnn RW v_dis_start 
Beginn der nutzbaren Bildschirmfläche 


Unterer Rand 

$ffff82aa W %XXXXXnnn nnnnnnnn RW v_dis_end 
Ende der nutzbaren Bildschirmfläche 


Vertical Sync Start 

$ffff82ad W %XXXXXXnnn nnnnnnnn RW v_sync_start 


Sync Mode Falcon 

$ffff82c0 W %XXXXXXXP nnnnnVnn syncjal 

Wenn gesetzt : P = Pal/NTSC 
V = VGA 


Pixel Höhe/Breite 

$ffff82c2 W %XXXXXXXX XXXX EBZH RW resolution 
H = Pixelhöhe, wenn gesetzt, doppelte Höhe 

Z = Zeilensprung, wenn gesetzt, wird je eine Zeile beim Auslesen 
des Bildschirmspeichers übersprungen 
B = Breite , wenn gesetzt, "320" Pixel pro Zeile sonst "640" 

E = Externe Synchronisation oder Pixelclock ??? 
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Farbpalette - 18 Bit = 262144 Farbtöne 

$FFFF9800 L %rrrrrrXX ggggggXX XXXXXXXX bbbbbbXX RW 
Fal_colO 

bis 

SFFFF9BF8 L %rrrrrrXX ggggggXX XXXXXXXX bbbbbbXX RW 
Fal_col255 

Achtung, auf diese Register darf nur lang/wortweise zugegriffen- 
werden, ein byteweiser Zugriff wirkt sich sowohl auf das nieder¬ 
wertige als auch auf das höherwertige Byte des jeweiligen Farbre- 
gisters aus. 
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B.2. Speicher schaufeln mit dem Blitter 

Ende 1987 wurde die ersten Blitter in die MEGA ST’s serienmäßig 
eingebaut. Ende 1989 wurden die ersten 1040 STE’s vekauft, in 
dessen Grafikchips wurde der Blitter gleich integriert. Ende 1990 
konnte man (endlich) den TT030 kaufen, leider enthält dieser kei¬ 
nen Blitter! 

Seit Anfang 1993 kann man den FALCON030 kaufen, in dessen 
Grafikchip wurde der Blitter auch gleich integriert und mit doppelter 
Taktfrequenz (16 Mhz) betrieben, d.h. er ist etwa doppelt so 
schnell wie der Standard-Blitter in den ST(E) Computern. 

Nun, das Fehlen eines Blitters fällt im TT eigentlich nicht ins Ge¬ 
wicht, jedoch bedeutet das für den Programmierer, daß er nicht da¬ 
von ausgehen kann, daß die ATARI Computer ohne Blitter irgend¬ 
wann aussterben würden. Was wiederum bedeutet, daß man min¬ 
destens zwei Bitblit- oder Sprite-Routinen schreiben muß, wenn 
man die Geschwindigkeit der Geräte voll ausnutzen möchte. Zum 
einen, eine die den Blitter nutzt und zum anderen natürlich eine, die 
das Ganze mit dem Prozessor erledigt (wer es richtig machen will, 
schreibt noch eine, die den 68030 voll ausnutzt). Ich kenne (leider) 
nur ein Spiel, das auch den Blitter nutzt, es ist ’Wings of Death’ von 
Thalion, das allerdings hartnäckig den Dienst auf dem TT verwei¬ 
gert. 

Programmierer, die auf dem ST/STE/TT/Falcon ... professionelle 
Anwender-Software schreiben, werden sich wohl “die Haare rau¬ 
fen", wenn sie schon wieder was von direkter Programmierung der 
Hardware hören, es ist jedoch (fast) unmöglich, gute GEM konfor¬ 
me Spiele mit flüssiger Animation zu schreiben, weil weder AES 
noch VDI Möglichkeiten bietet, mehrfarbige Sprites oder sonst ir¬ 
gend etwas mit dem Bildaufbau des Monitors zu synchronisieren. 
Es bleibt uns also nichts anderes übrig, als in den "sauren Apfel" 
zu beißen und den Blitter selbst zu programmieren. "Immer ?" - 
"Nein, nicht immer - aber..." 
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2.1 Die Hardwareregister des Blitters 

Der Blitter ist fast "nur" die hardwaremäßige Realisierung des Line 
A - Bitblit Befehls bzw. Copy Raster, Opaque (VDI 109) des VDI 
(der ja auf Bitblit zurückgreift). Allerdings untestützt der Blitter 
auch das Füllen von Flächen mit Mustern, da er einen speziellen 
Speicher für Füllmuster, das Halftone-Ram, besitzt. Wie in anderen 
Kapiteln erwähnt, ist der ATARI nicht speziell als Spielkonsole ent¬ 
wickelt worden und so wurde auch der Blitter eher als Unterstüt¬ 
zung des Betriebssystems konzipiert. Aber es gibt eben nichts, 
was man nicht in irgendeiner Weise zum Spielen "mißbrauchen" 
könnte. 

Spötter behaupten, der Blitter wäre der Versuch Atari’s gewesen, 
das durch die Unfähigkeit seiner Programmierer zu langsam gera¬ 
tenen VDI durch Verbesserung der Hardware zu beschleunigen. 


2.1.1 Register zur Definition des Quellbitfelds 

Halftone-Ram: 

$ff 8A00 bis $FF 8A1E (16 Wörter) 

Den Inhalt des Halftone-Ram kann man als Quelle als auch zur 
Verknüpfung mit den Quelldaten nutzen. 


Source X Increment: 

$ff 8A20 W %nnnnnnnn nnnnnnnX RW Src_Xinc 

Gibt an, wieviel Bytes der Blitter zwischen den zu lesenden Wör¬ 
tern der Quelldaten überspringen soll. Nimmt vorzeichenbehaftete 
Integer-Werte an und wertet sie gemäß ihres Vorzeichens aus. 
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Source Y increment: 

$FF 8A22 W %nnnnnnnn nnnnnnnX RW Src_Yinc 

Gibt den Offset in Bytes zwischen dem letzten Wort einer Zeile 
zum ersten der nächsten Zeile an. Nimmt vorzeichenbehaftete In¬ 
teger-Werte an und wertet sie gemäß ihres Vorzeichens aus. 

Source-Adress-Register: 

$FF 8A24 L %XXXXXXXX nnnnnnnn nnnnnnnn nnnnnnnX RW 
Src_Addr 

Hier wird die Anfangsadresse der Quelle eingetragen. 

Masken - Register: 

Dienen zum Ausmaskieren der Bits in den Wörtern des Zielbitfel¬ 
des. 

Die in diesen Registern gesetzten (!) Bits werden im Zielbitfeld 
ausmaskiert. 

$FF 8A28 W %nnnnnnnn nnnnnnnn RW Endmaskl 
Nur für das erste Wort einer Zeile. 

$FF 8A2A W %nnnnnnnn nnnnnnnn RW Endmask2 
Für alle Wörter zwischen erstem und letztem Wort einer Zeile. 

$FF 8A2C W %nnnnnnnn nnnnnnnn RW Endmask3 
Nur für das letzte Wort einer Zeile. 
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2.1.2 Register zur Definition des Zielbitfeldes 

Destination X increment: 

$FF 8A2E W %nnnnnnnn nnnnnnnx RW Dst_Xinc 
Funktion wie bei Source X increment! 

Destination Y increment: 

$FF 8A30 W %nnnnnnnn nnnnnnnX RW Dst_Yinc 
Funktion wie bei Source Y increment! 

Destination Adress: 

$FF 8A32 L %XXXXXXXX nnnnnnnn nnnnnnnn nnnnnnnX RW 
Dst_Addr 

Startadresse des Zielbitfeldes 

X-Count-Register: 

$FF 8A36 W %nnnnnnnn nnnnnnnn RW X_Count 

Gibt die Anzahl der Worte in einer Zeile an. Bei Abarbeitung einer 
Kopieroperation wird das Register mit jedem bearbeiteten Wort 
heruntergezählt. Wenn das Register 0 ist, wird es wieder auf sei¬ 
nen Startwert gesetzt. 

Y-Count-Register: 

$FF 8A38 W %nnnnnnnn nnnnnnnn RW Y_Count 
Gibt Anzahl der zu bearbeitenden Zeilen an. 

Bei Abarbeitung einer Kopieroperation wird das Register mit nach 
Bearbeiten einer Zeile heruntergezählt. Wenn das Register Null ist, 
wird es wieder auf seinen Startwert gesetzt. 
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2.1.4 Operations Register des Blitters 

Halftone Operation Register: 

$FF 8A3A B %XXXXXnnn RW HOP 

Wird gesetzt je nach Verwendung des Halftone-RAM ! 

Inhalt Bedeutung 
0 Alle Bits 

1 Nur Halftone Daten 

2 Nur Source Daten 

3 Source AND Halftone 

Operation Register: 

$FF 8A3C B %XXXXnnnn RW OP 

Wie bei RC_COPY oder PUT und GET in GFA - BASIC wird hier 
die Art der Verknüpfung festgelegt. 

Inhalt Bedeutung 

0 Alle Bits werden gelöscht 

1 Quelle AND Ziel 

2 Quelle AND NOT(Ziel) 

3 nur Quelle 

4 NOT(Quelle) AND Ziel 

5 Ziel 

6 Quelle XOR Ziel 

7 Quelle OR Ziel 

8 NOT(Quelle) AND NOT(Ziel) 

9 NOT(Quelle) XOR Ziel 

A NOT (Ziel) 

B Quelle OR NOT(Ziel) 

C NOT(Quelle) 

D NOT(Quelle) OR Ziel 

E NOT(Quelle) OR NOT(Ziel) 

F Alle BITS werden gesetzt 
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Line Number: 

$FF 8A3C B %nnnXnnnn RW Line_Num 

Bit Wirkung 

0-3 Line Number 

Gibt an, welches Wort des Halftone-RAM verwendet wird. 
Wird abhängig vom ’Dst_Yinc’ Register (je nach vor Vor¬ 
zeichen) erhöht bzw. erniedrigt. 

5 Smudge 

Wenn das Bit gesetzt wird, betimmt der Inhalt der untersten 
4 Bit des Quellbitfelds, welches Wort des Halftone-RAMs 
verwendet wird. 

6 HOG 

Wenn dieses Bit gesetzt ist, hat der Blitter Vorrang bei 
Buszugriffen. Wenn es gelöscht ist, wechseln sich Blitter 
und Prozessor alle 64 Buszyklen ab. 

7 BUSY 

Startet den Blitter 

Das Skew Register: 

$FF 8a3D B %nnxxnnnn RW Skew 

Bit Wirkung 

0-3 Skew 

Gibt an, um wieviel Stellen die Datenwörter, die vom Quell¬ 
bitfeld stammen, nach rechts geshiftet werden, wobei die 
überzähligen Bits ins folgende Datenwort geschoben wer¬ 
den. 

6 NFSR (No Final Source Read) 

Ist dieses Bit gesetzt, wird das letzte Datenwort einer Zeile 
der Quelle ignoriert. 

7 FXSR (Force EXtra Source Read) 

Ist dieses Bit gesetzt, wird noch ein zusätzliches Wort am 
Anfang jeder Zeile gelesen. 
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2.2 Was man bei der Blitter-Programmierung 
beachten sollte! 

Prinzipiell funktioniert das Bewegen von Blöcken von einem Spei¬ 
cherbereich in den anderen mit dem Blitter genauso einfach wie mit 
einer selbstgeschriebenen Routine. Allerdings nimmt der Blitter 
dem Programmierer den kompliziertesten Teil der Arbeit (das Pro¬ 
grammieren einer Routine !) ab, so daß man eigentlich nur Start¬ 
adresse des Blocks, Zieladresse des Blocks, Zeilenbreite usw. ein¬ 
geben muß, die restlichen Register mit Default-Einstellungen bele¬ 
gen muß und schon macht der Blitter (fast) alles von allein. Dazu 
befindet sich ein Beispiel-Listing auf der Diskette ! 


2.2.1 Welche Register ändern sich nach dem Start ? 

Wichtig ist zu wissen, daß man beim erneuten Starten des Blitters 
nicht alle Register neu beschreiben muß. Nur die Register mit den 
Startadressen der Quelle und die Menge der zu kopierenden Zeilen 
werden effektiv vom Blitter verändert, alle anderen Blitterregister 
(außer dem Busy-Bit zum Starten des Bitters im Line_Num Regi¬ 
ster) behalten ihre alten Werte. In vielen Fällen kann man somit 
durch Beschreiben von 12 Bytes im Blitterregister ganze Bild¬ 
schirmseiten kopieren. Natürlich darf man nach Benutzen von LINE 
A oder VDI, falls man nicht mit Blitmode dem VDI/LINE A die Be¬ 
nutzung des Blitters verboten hat, alle Blitterregister wieder initiali¬ 
sieren. 


2.2.2 Nutzung des Blitter in unterschiedlichen Auflösungen 

Muß man, durch die etwas ungünstige Lage der Bitplanes, in den 
Auflösungen bis 8 Bit Tiefe den Blitter für jede Bitplane einzeln be¬ 
mühen, kann man in den 16 Bit "Echtfarbauflösungen" des 
Falcon030 mit einem einzigen Start des Blitters einen Rasterko¬ 
pierbefehl erledigen, da in dieser Auflösung ein Bildpunkt einem 
Datenwort des Blitters entspricht. 
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Einstellung für X - Increment je nach Auflösung 

mono/duocrome 1 
4 Farben 4 

16 Farben 8 

256 Farben 16 

"TRUE" Color 1 

Bei den paletteorientierten Auflösungen muß man beim Kopieren ei¬ 
nes Bitblocks pro Plane eine Blitteroperation durchführen lassen. 

Im Falcon "TRUE" Color Mode lassen sich durch direkte Program¬ 
mierung des Blitter interessante Effekte erzielen. So läßt sich, ein¬ 
fach durch Setzen des X - Increments der Quelle auf zwei, der 
Bildschirm horizontal halbieren. Auch kann man durch zusätzliche 
Programmierung des X - Increments des Ziel und entsprechenden 
Kopieroperationen den Bildschirm in Y Richtung leicht um das X - 
fache dehnen oder stauchen. Natürlich lassen sich in allen Auflö¬ 
sungen mit Hilfe des Blitters solche Effekte in Y Richtung erzeu¬ 
gen. 


2.2.3 Die Betriebsmodi des Blitters 

Wie schon erwähnt, läßt sich mittels des HOG Bits im ’Line_num’ 
Register die Betriebsart des Blitters festlegen. Bei gelöschtem Bit 
teilen sich Prozessor und Blitter den Zugriff auf den Bus im Wech¬ 
sel von 64 Zyklen, wobei jeweils Blitter oder Prozessor, während 
der andere dran ist, nicht mehr auf den Bus zugreifen können. Da 
der Blitter am 103 Port des MFP angeschlossen ist, kann man ei¬ 
nen Interrupt auslösen lassen, wenn der Blitter seine Operation be¬ 
endet hat. 

Wenn das HOG Bit gesetzt ist, bekommt die CPU nur noch den 
Bus, wenn der Blitter ihn zwischendurch frei gibt. Da der Blitter 
jetzt bei jedem Taktzyklus zum Zug kommt, und nicht nur alle 64 
Zyklen mal 64 Zyklen, ist er in diesem Modus doppelt so schnell 
wie bei gelöschtem HOG Bit. Der Nachteil ist jedoch, daß während 
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der Blitter läuft, der Prozessor keine Interrupts mehr durchführen 
kann. Wenn also der Blitter ohne Unterbrechung läuft, reicht die 
Zeit möglicherweise nicht mehr für den Maus/Keyboard Interrupt, 
d.h. Daten der Pakete vom IKBD (Intelligent KeyBoarD Processor) 
nicht abgeholt werden können und somit unvollständig ans Be¬ 
triebssystem geliefert werden, was den Mauspfeil recht seltsam 
reagieren lassen kann ! 


2.3 Betriebssystem-Unterstützung des Blitters 

Ab TOS 1.02 wird vom Betriebssytem beim Sytemstart das Vor¬ 
handensein eines Blitters überprüft. Das TOS testet die Anwesen¬ 
heit des BLitters durch den Versuch, dessen Register zu beschrei¬ 
ben; ein ST ohne Blitter reagiert auf einen solchen Versuch mit ei¬ 
nem Busfehler, die 68000er Familie springt bei einem Busfehler an 
eine Stelle, die, fall das Vector Basis Register Null ist, an der 
Adresse $08 steht. Das Betriebssystem schreibt vor dem Test an 
$08 die Adresse einer Routine, die dann ein internes Flag setzt, 
was soviel bedeutet wie: kein Blitter vorhanden. Nachfragen kann 
man das ganze via XBIOS 64. 

Nomenklatur: 

WORD = 16 Bit 
LONG =32 Bit 

VOID = Dummy, d.h. keine Rückgabe 
* = Zeiger auf 

XBIOS 64 

WORD Blitmode(WORD mode) 

Mit diesem Aufruf kann man dem Betriebssystem die Benutzung 
des Blitters untersagen (nicht beim Falcon030), so daß das 
VDI(ROM -Treiber)/LINE A nur die CPU zum Realisieren der Gra¬ 
fikfunktionen gebrauchen dürfen. 
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Aufruf in Assembler: 

move.w #mode,-(sp) 
move.w #64,-(sp) 

trap #14 

addq.l #4,sp 

mode, -1 gibt eingestellten Wert zurück 
Bit 0 gesetzt, Blitter an 
Bit 0 gelöscht, Blitter aus 

gibt zurück: 

Bit 0 =0 Blitter wird nicht benutzt 
= 1 Blitter wird benutzt 
Bit 1 =0 kein Blitter vorhanden 
= 1 Blitter vorhanden 

Bit 15 immer 0 

alle restlichen Bits sind reserviert! 
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B.3. Der MFP , so wie ihn ein Spieleprogrammierer benutzt 
Was des einen Copper (AMIGA CHIP) ist des anderen MFP ! 

Wer sich einige der neueren Spiele für den ST angesehen hat, sieht 
Farben, nichts als Farben. Wie war das noch mal (?) nur vier Bit¬ 
planes (!) das sind doch "nur" sechzehn Farben ??? Ja, im Prinzip 
schon (!) aber man kann die Farbregister des Shifters beschreiben 
und dieser reagiert sofort auf den neuen Inhalt. 

Auch gibt es einige Adventures, die bis zu einem bestimmten Punkt 
eine LORES (320*200*4) 16 Farb-Darstellung zeigen aber an der 
Stelle wo man die Komandos eingibt, diese in der mittleren Auflö¬ 
sung (640*200*2) eingeben darf. Das liegt wiederum darin begrün¬ 
det, daß der Inhalt eines Hardwareregisters sofort in den Shifter 
übernommen wird. In diesem Fall ist es das SHIFT MODE Regi¬ 
ster. 

Nun, wenn diese Register sofort übernommen werden, dann muß 
man sie immer exakt zum richtigen Zeitpunkt beschreiben, um syn¬ 
chron zum Bildaufbau die Färb oder Auflösungsumschaltung vorzu¬ 
nehmen, denn wenn man das nicht schaft, werden die Bilder nicht 
mehr ganz so schön wie man sich das eigentlich vorgestellt hatte. 

Viele Spieleprogrammierer versuchen, eine Vielzahl von Farben auf 
dem Bildschirm zu erreichen, indem sie den Bildaufbau mit dem mit 
den Ausführungszeiten der Befehle synchronisieren (siehe dazu 
auch Kapitel B.1.4). Jedoch bekommt man damit unwillkürlich Pro¬ 
bleme, wenn der Rechner mit einen schnelleren Prozessor ausge¬ 
rüstet ist (wie z.B. beim TT oder Falcon dem Fall), da das Pro¬ 
gramm, aufgrund der höheren Ausführungsgeschwindigkeit, das 
Bild schneller im Speicher aufbaut und die Farben umschaltet als 
der Monitor für den Bildaufbau auf dem Bildschirm benötigt. Proble¬ 
me gab’s mit einigen Spielen auf dem TT, die dann entweder beim 
Bildaufbau flackerten oder unbedingt auf 50Hz schalten wollten, 
weil ihre Routine zum Bildaufbau auf diese Frequenz syncronisiert 
worden ist. Nun, ein Chip, der - egal wie hoch der Prozessor ge¬ 
taktet ist - immer zur richtigen Zeit umschaltet, ist der MFP mit 
seinen Timern. 
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3.1 Der MFP (Multi Function Peripheral) 

Der MFP 68901 ist, wie der Name schon sagt, ein Peripherie-Bau¬ 
stein, der sehr universell einsetzbar ist. Auf die technischen Ein¬ 
zelheiten zu diesem Chip wird schon in vielen anderen Büchern 
eingegangen, daher möchte ich nur das für den Spieleprogrammie¬ 
rer Wichtige erwähnen. 

Jeder ST besitzt einen MFP, der TT sogar zwei. Jeder MFP, so¬ 
wohl der im ST/STE/Falcon als auch die zwei im TT, werden mit 
2,4756MHz getaktet. Alle Interrupts der Timer werden durch Vor¬ 
teiler aus diesem Systemtakt erzeugt. 

Der MFP besitzt verschiedene Ein/Ausgänge, die je nach Einstel¬ 
lung bei einer Änderung der angelegten Spannung, von High (5V) 
auf LOW (0V) einen Interrupt auslösen können. Wichtig für den 
Spieleprogrammierer ist dabei der Timer B, der an dem Display 
Enable Signal des Video-Sub-Systems anliegt, was wiederum nicht 
anderes bedeutet, daß es bei entsprechender Einstellung möglich 
ist, alle n<256 Zeilen einen Interrupt auszulösen um z.B. die Farb- 
register zu ändern (dazu später mehr). Bei STE/TT/Falcon liegt am 
Timer A Eingang (unter anderem) ein Signal vom DMA-Sounchip 
an, der beim letzten Füllen seines Abspielpuffers einen Interrupt 
auslöst. Auch erzeugt der MFP einen Interrupt, wenn der Blitter 
seine Arbeit beendet hat. Diese Verschaltung des MFP mit anderen 
Bausteinen der Video/Audio Hardware machen diesen Bustein für 
uns Spieleprogrammierer höchst interessant. Interessant ist natür¬ 
lich auch, daß der MFP einen Interrupt erzeugt, damit die CPU die 
Maus-, Joystick- und Keyboard-Daten von den ACIAS (Übertra¬ 
gungsbausteine), die mit dem IKBD (Prozessor für die Verwaltung 
von Keyboard-, Joystick- und Maus-Daten) abholt. 

Im Prinzip wird also fast alles verwaltet, was wir so brauchen. Da¬ 
her ist es wichtig zu wissen, wie man ihn programmiert. 
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3.2 Die Programmierung der MFPs 

3.2.1 Die Hardwareregister des ST - MFP 

Achtung, ich nenne den MFP, der in allen ATARI Rechnern (STE/TT/F030) 
enthalten ist, ST - MFP. 


Gpip Data Register 

gpip 

Centr. Port, Drucker beschäftigt 
RS 232, Data Carrier Detect 
RS 232, Clearto send 
GPU Done, Blitter fertig 
CLKDIR (nur im TT) 

IRQ, MIDI - Tastatur ACIA 
Meldung von ASCI/FDC 
RS 232 Ring Indikator 
Monochrome Monitor Detect 
beim (STE/TT) XOR mit 
Frame-End Signal vom 
DMA Sound Subsystem 

Liefert die logischen Pegel der Anschlüsse. Nun zu den für uns 
wichtigen Bits ! 

Bit 3, GPU Done 

Wenn dieses Bit gelöscht ist, hat der Blitter seine Arbeit beendet. 
Siehe dazu auch das Kapitel B.2 zur Blitterprogrammierung. 

Bit 4, MIDI/Tastatur ACIA 

Je nach Modus liefert der IKBD (Tastaturprozessor) Maus, Joy¬ 
stick und Tastatur Daten, die von der CPU per Interrupt in den 
Registern der ACIA (Asyncron-Communications-Interface-Adap- 
ter) abgeholt werden müssen. 

Bit 7, Monocrome Detect, bei STE/F030/TT XOR mit 


$fffa01 B %nnnnnnnn R 

I I I I I I I I Bit 

I I I I I I I I_ 0 

I I I I I I I_ 1 

I I I I I I_2 

I I I I I_3 


4 

5 

6 
7 
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Frame-End-Signal 

Im VBL fragt das Betriebssystem das Monochrome Detect Bit ab, 
bei gelöschtem Bit ist der Rechner an einen monochromen Monitor, 
bei gesetztem Bit an ein Farbmonitor angeschlossen. Wenn die ein¬ 
gestellte Auflösung nicht mit dem angeschlossenen Monitor über¬ 
einstimmt, wird im VBL ein Warmstart (Reset ohne Löschen des 
Speichers) ausgelöst und damit die Auflösung geändert. Bei einem 
ATARI mit 8 Bit DMA Sound-Subsystem wird das Monochrome 
Monitor Detect Signal noch mit dem DMA Sounchip XORed exklu¬ 
siv geodert, siehe dazu auch Kapitel B.3 über Sounderzeugung. 


Das Active Edge Register 

$fffa03 B %nnnnnnnn RW aer 

Belegung der Bits siehe ’gpip’ 

Sinn dieses Registers ist es festzulegen, wann ein Interrupt ausge¬ 
löst wird. Das hängt mit der Interruptquelle, die am MFP anliegen 
zusammen. Wenn am Eingang einer Quelle plötzlich OV (low) statt 
5V (high) anliegen, wird nur dann ein Interrupt ausgelöst, wenn das 
entsprechende Bit (siehe gpip) gesetzt ist. Bei gelöschtem Bit wird 
ein Interrupt bei einer Änderung von high auf low ausgelöst. 
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Das Data Direction Register 

$fffa05 B %nnnnnnnn RW ddr 

Belegung der Bits siehe ’gpip’ 

Man kann mit diesem Register angeben, ob die l/O’s des MFP als 
Eingänge oder Ausgänge verwendet werden, da die bisher verwen¬ 
deten I/O’ Leitungen alle als Eingänge verschaltet sind, sind die 
Bits in diesen Registern alle gelöscht. 


Das Interrupt-Enable-Register A 


$fffa07 B % 


nnnnnnnn RW iera 


III Bit 

III_ 0 

I I_1 

I_ 2 

_ 3 

_4 

_ 5 


6 

7 


Timer B (Display enable Signal) 
XMIT Fehler (RS 232) 

XMIT Puffer leer (RS 232) 

RCV Fehler (RS 232) 

RCV Puffer voll (RS232) 

Timer A 

Timer A (Frame end bei 
STE/TT/Falcon 8 Bit DMA Sound) 
Port 16 (RS 232 Ring Indikator) 
Port 17 (Monochrome Detect) 


Mit diesem Register kann man das Erzeugen eines Interrupts ver¬ 
hindern, indem man das entsprechende Bit aus dem Register 
löscht. 


195 















Spiele selbst programmieren 


Die wichtigsten Bits: 

Bit 0, Timer B (Display enable Signal) 

Durch das Einschalten dieses Interrupts ist es möglich, in einer be¬ 
liebigen Bildschirmzeile (0 bis 255) einen Interupt auslösen zu las¬ 
sen. Mit entsprechender Programmierung ist es damit möglich, den 
Bildschirm in mehrere Zonen mit unterschiedlichen Farben einzu¬ 
teilen (sogenannte Rasterinterrupts) oder änllich wie schon bei den 
8 Bit-Atari’s von einer zur anderen Zeile die Auflösung zu wechseln 
(bei den 8 Bit-Geräten bekannt unter dem Namen "Display Listen 
Interrupt"). Auch Splitscreens (bei STE/TT/Falcon) und bei 
STE/Falcon sogar unabhängiges Fine-Scrolling der Splitscreens 
wird durch geschickte Programmierung möglich. Nicht zu verges¬ 
sen, ohne diesen Interrupt wäre das Öffnen des unteren Bild¬ 
schirmrandes bei ST/STE "unmöglich". Allerdings kann man den 
Timer B auch "nur" als Timer benutzen, der nach einer gewissen 
Zeit einen Interrupt auslöst. 

Bit 5, Timer A 

Natürlich ist auch der Timer A ein Timer, der nach einer gewissen 
Zeit einen Interrupt auslösen kann. Allerdings ist es auch möglich, 
sofern es sich um einen STE/TT/Falcon handelt, den Timer A im 
Event-Count-Modus DMA-Sound Frame End’s (siehe Kapitel 4) 
zählen und gegebenenfalls einen Interrupt auslösen zu lassen. 

Bit 7, Port 17 (Monochrome Detect) 

Wird im Atari nicht benutzt, ob ein MONOCHROME Monitor ange¬ 
schlossen ist, wird vom Betriebssytem während des VBL’s am 
’GPIP’ Bit 7 getestet. Auch dieser Interrupt kann beim 
STE/TT/Falcon030 bei Frame End ausgelöst werden. 
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Das Interrupt Enable Register B 

$fffa09 B% nnnnnnnn RW ierb 
I I I I I I I I Bit 

I I I I I I I I _ 0 Port 10 (Busy Centronics) 

I I I I I I_ 1 Port II (RS232 Data Carrier Detect) 

I I I I I I_ 2 Port 12 (RS232 Clear To Send) 

I I I I I_ 3 Port 13 (GPU Done, nur mit Blitter) 

I I I I_ 4 Timer D (Baudrate RS232) 

I I I_ 5 Timer C (200 Hz System (AES etc.)) 

I I _ 6 Port 14 (IRQ IKBD/Maus/MIDI) 

I_ 7 Port 15 (IRQ Floppy Hardd. DMA) 

Funktion wie Interrupt-Enable-Register A ! 

Die wichtigsten Bits: 

Bit 3,13 (GPU done) 

Erzeugt einen Interrupt, wenn der Blitter seine Arbeit beendet hat, 
siehe dazu auch Blitterprogrammierung. 

Bit 5, Timer C (200Hz Timer) 

Dieser Interrupt bietet sich an, auf eigene Soundroutinen zum Ab¬ 
spielen von Musik verwendet zu werden. Dabei sollte man Vektor 
256 benutzen, der 50 mal pro Sekunde, also bei jedem vierten Auf¬ 
ruf von Timer C, von der Timer C Routine aufgerufen wird. Diesen 
Vektor kann man mit ’Setexec’ also BIOS 5 auf eine eigene Routine 
umbiegen. 

Bit 6, Port 14 (Joystick, Keyboard, MIDI, Mouse) 

Dieser Interrupt wird immer dann ausgelöst, wenn ein Paket vom 
IKBD abgeholt werden soll, wobei das dann Maus, Keyboard oder 
Joystickdaten sein können. Außerdem wird der Interrupt ausgelöst, 
wenn am MIDI Port Daten anliegen. Die Daten müssen dann von 
der jeweiligen ACIA (Asyncrone - Communications - Interface - 
Adapter) abgeholt werden. Von welcher ACIA die Daten abzuholen 
sind, kann die Interruproutine durch Prüfen der ACIA Statusregi¬ 
ster ermitteln. 
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Das Interrupt Pending Register A 
SfffaOB B %nnnnnnnn RW ipra 
Belegung siehe Interrupt Enable Register A 

Entsprechende Bits werden beim Auftreten eines Interrupts gesetzt 
und nach dem Erzeugen des Vektors - oder wenn der Prozessor 
den Interrupt anerkannt hat - wieder gelöscht. Hat man zuvor 
selbst das entsprechende Bit gelöscht (Dazu muß ein Byte in das 
Register geschrieben werden, in dem alle Bits gesetzt sind, die 
nicht gelöscht werden sollen) wird der Interrupt nicht ausgelöst. 


Das Interrupt Pending Register B 

$fffaOd B %nnnnnnnn RW iprb 

Belegung siehe Interrupt Enable Register B 
Funktion siehe Interrupt-Pending-Register B 


Das Interrupt In Service Register A 
$fffaOf B %nnnnnnnn RW iera 
Belegung siehe Interrupt Enable Register A 

Wie schon der Name schon sagt, zeigt dieses Register an, wann 
ein Interrupt abgearbeitet wird. Das entsprechende Bit in diesem 
Byte wird dann gesetzt, wenn das Bit im Pending Register gelöscht 
wird. Im Automatic End of Interrupt (AEOI) wird das Bit aber dann 
auch gleich wieder gelöscht und für den MFP ist dieser Interrupt 
beendet, es können also neue Interrupts oder nochmal die gleiche 
Interruptanforderung auftreten, diese werden ausgeführt, wenn in 
der gerade laufenden Interruptroutine der Interrupt Level im Status¬ 
register heruntergesezt wurde. Im Software End Of Interrupt 
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(SEOI) kann kein MFP-Interrupt mit niedrigerem Interruptlevel als 
dem gerade laufenden ausgeführt werden, solange das In Service 
Bit gesetzt ist. Für Interrupts mit niedrigerem Level wird aber das 
Pending Bit gesetzt, was wiederum das Erzeugen eines Vektors 
nach dem Löschen des Interrupt in Service Bits nach sich zieht. 


Das Interrupt in Service Register B 

$fffa11 B %nnnnnnnn RW ierb 

Belegung siehe Interrupt Enable Register B 
Funktion siehe Interrupt in Service Register A 


Das Interrupt Mask Register A 
$fffa13 B %nnnnnnnn RW imra 
Belegung siehe Interrupt Enable Register A 

Mit diesem Register ist es möglich, angeforderte Interrupts auszu¬ 
maskieren. Was so viel bedeutet wie, die Interrupts werden dem 
MFP zwar gemeldet und er setzt das Pending Bit, sie werden aller¬ 
ding nicht der CPU gemeldet also kein Vektor generiert, was nichts 
anderes heißt, als daß der Interrupt nicht ausgeführt wird. Ein ge¬ 
löschtes Bit in diesem Register maskiert den Interrupt aus. 


Das Interrupt Mask Register B 

$fffa15 B %nnnnnnnn RW imrb 

Belegung siehe Interrupt-Enable-Register B 
Funktion siehe Interrupt-Enable-Register B 
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Das Interrupt Vektor Register 

$fffa17 B %wwsXXX RW vr 

Mit dem ’s’ Bit kann man zwischen Sowtware End of Interrupt oder 
Automatic End of Interrupt umschalten. Es ändert sich dabei das 
Verhalten des MFP auf den Interrupt. Die ’ww’ Bit bilden das obe¬ 
re Nibble für die Vektortabelle des MFP, das untere bildet sich aus 
dem Level (Prirorität) des Interrupts, der Werte von Null bis fünf¬ 
zehn annehmen kann. 

wvv = oberes Nibble der Interruptvektoren 
s = wenn gesetzt, Software EOI sonst Automatic EOI 


Das Timer A Control Register 

$fffa19 B %XXXXnnnn RW tacr 

nnnn, Bit Nr. 

3210 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


0000 

0001 

0010 

0011 

0100 

0101 

0110 

0111 

1000 

1001 

1010 

1011 

1100 

1101 

1110 

1111 


TIMER gestopped 
Delay Mode, Vorteiler 4 
Delay Mode, 

Delay Mode, 

Delay Mode, 

Delay Mode, 

Delay Mode, 

Delay Mode, 


Vorteiler 10 
Vorteiler 16 
Vorteiler 50 
Vorteiler 64 
Vorteiler 100 
Vorteiler 200 


Event Count Mode, Zählen von Ereignissen 


Pulsbreitenmessung, 

Pulsbreitenmessung, 

Pulsbreitenmessung, 

Pulsbreitenmessung, 

Pulsbreitenmessung, 

Pulsbreitenmessung, 

Pulsbreitenmessung, 


Vorteiler 4 
Vorteiler 10 
Vorteiler 16 
Vorteiler 50 
Vorteiler 64 
Vorteiler 100 
Vorteiler 200 
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Im Delay Mode kann über einen Vorteiler die am MFP anliegende 
Taktfrequnez von 2,4576 Mhz geteilt werden und als Interruptquelle 
genutzt werden. 

Im Event Count Mode kann man Ereignisse wie z.B. Frame End 
beim DMA Sound als Interruptquelle benutzen. 

Mit der Pulsbreitenmessung kann man die Zeit zwischen einem 
Flankenwechsel am TAI Eingang messen. 

Das Timer B Control Register 
$fffa1B B %XXXXnnnn RW tbcr 
Funktion wie bei Timer A Control Register 

Das Timer C Control Register 
$fffa1D B %XcccXdddX tacr 
Näheres siehe Timer A Control Register 
ccc und ddd, Bit Nr. 
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0 

1 

2 

3 

4 

5 

6 
7 


000 TIMER gestopped 


001 Delay Mode, Vorteiler 4 
010 Delay Mode, Vorteiler 10 
011 Delay Mode, Vorteiler 16 

100 Delay Mode, Vorteiler 50 

101 Delay Mode, Vorteiler 64 

110 Delay Mode, Vorteiler 100 

111 Delay Mode, Vorteiler 200 
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Das Timer A Data Register 

Sfffalf B %nnnnnnnn RW tadr 

Der im Timer A Data Register enthaltenen Wert wird beim Auftre¬ 
ten eines Ereignisses, z.B. wenn die angegebene Delay Zeit abge¬ 
laufen ist, um eins herunter gezählt. Wenn das Data Register von 
eins auf Null wechseln würde wird im Regelfall der Interrupt ausge¬ 
löst und der ursprüngliche Wert im Data Register wieder herge¬ 
stellt. Wenn der Timer gestartet ist und ein Wert ins Data Register 
geschrieben wird, wird dieser beim nächsten Durchlauf Startwert. 
Bei gestopptem Timer wird der ins Data Register geschriebene 
Wert sofort übernommen. 


Das Timer B Data Register 
$fffa21 B %nnnnnnnn RW tbdr 
Funktion wie Timer A Data Register 

Das Timer C Data Register 
$fffa21 B %nnnnnnnn RW tcdr 
Funktion wie Timer A Data Register 

Das Timer D Data Register 
$fffa21 B %nnnnnnnn RW tddr 
Funktion wie Timer A Data Register 
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Die Erklärung der MFP-USART Register entfällt, da die serielle 
Schnittstelle beim Falcon030 mit dem SCC (Serial Communicati¬ 
ons Controller), der auch in TT/F030 für die LAN (Local Area Net¬ 
work) Schnittstelle zuständig ist, realisiert wurde, die direkte Pro¬ 
grammierung dieser Schnittstelle also nicht auf jedem Rechner so 
funktionieren würde. Außerdem ist diese Schnittstelle für das Pro¬ 
grammieren von Spielen auch nur in seltenenen Fällen (z.B. Kop¬ 
peln zweier Rechner bei Flugsimulatoren) interessant. 


з. 2.2 Die Hardwareregister des TT - MFPs 

Der TT hat noch einen zweiten MFP, der allerdings nicht so ohne 
weiteres zu programmieren ist, da für diesen Zweck die entspre¬ 
chenden Betriebssystem-Funktionen fehlen. Er wird z.B. für die 
zusätzlichen seriellen Schnittstellen und die SCSI DMA (meldet 
Ende der Übertragung eines Blocks) benötigt. 

Der TT MFP ist aber auch für Spieleprogrammierer interessant, da 
der ST - MFP bei einem sauber geschriebenen Spiel doch schon 
mit digitalem Sound, Farbumschaltungen, Sequenzersteuerung 

и. v.m. ausgelastet sein kann und man hier und da doch gern noch 
einen zusätzlichen Timer zur Verfügung hätte. 


Alle Erklärungen zu den Funktionen der Register siehe ST - MFP! 

Gpip Data Register 


$fffa81 B % 


nnn RW 

gpip-tt 

III Bit 


III 0 

nicht belegt 

1 1 1 

nicht belegt 

1 2 

SCC DMA 


. 3 Ring Indikator Modem 2 

4 Floppy Pin 34 

5 SCSI DMA Busfehler 

6 TT Uhrenchip 

7 SCSI DMA 
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Das Active Edge Register 

$fffa83 B %nnnnnnnn RW aer_tt 

Belegung der Bits siehe ’gpip’ 

Das Data Direction Register 

$fffa85 B %nnnnnnnn RW ddr_tt 

Belegung der Bits siehe ’gpip’ 


Das Interrupt Enable Register A 


$fffa87 B% nnnnnnnn RW iera_tt 


III Bit 

I I I_ 0 

I I_ 1 

I_ 2 

_ 3 

_ 4 

_ 5 

_ 6 

_ 7 


Timer B (Display enable Signal) 

XMIT Fehler (RS 232) 

XMIT Puffer leer (RS 232) 

RCV Fehler (RS 232) 

RCV Puffer voll (RS232) 

Timer A (unbenutzt) 

Port 16 (TT-Uhrenchip/IRQ Anschluß) 
Port 17 (IRQ von SCSI Contr. Chip) 
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Das Interrupt Enable Register B 

$fffa89 B % nnnnnnnn RW ierb_tt 
I I I I I I I I Bit 

I I I I I I I I_ 0 Port 10 (Pin 1 des J602 Steckers) 

I I I I I I I_ 1 Port II (Pin 3 des J602 Steckers) 

I I I I I I _ 2 Port 12 (IRQ von SCO DMA) 

I I I I I_ 3 Port 13 (Ring Indicator Modem 2) 

I I I I _4 Timer D (Baudrate Serial 1) 

I I I _ 5 Timer C(TCCLK ans SCC Channel 2) 

I I _ 6 Port 14 (Pin 34 Floppy) 

I _7 Port 15 (IRQ von SCSI DMA) 

Das Interrupt Pending Register A 
$fffa8B B %nnnnnnnn RW ipra_tt 
Belegung siehe Interrupt-Enable-Register A 

Das Interrupt Pending Register B 

$fffa8d B %nnnnnnnn RW iprb_tt 

Das Interrupt In Service Register A 
$fffa8f B %nnnnnnnn RW iera_tt 
Belegung siehe Interrupt-Enable-Register A 

Das Interrupt in Service Register B 
$fffa91 B %nnnnnnnn RW ierb_tt 
Belegung siehe Interrupt-Enable-Register B 
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Das Interrupt Mask Register A 
$fffa93 B %nnnnnnnn RW imra_tt 
Belegung siehe Interrupt Enable Register A 

Das Interrupt Mask Register B 

$fffa95 B %nnnnnnnn RW imrb_tt 
Belegung siehe Interrupt-Enable-Register B 

Das Interrupt Vektor Register 

$fffa97 B %wwsXXX RW vr_tt 

Das Timer A Control Register 

$fffa99 B %XXXXnnnn RW tacr_tt 

Das Timer B Control Register 

$fffa9B B %XXXXnnnn RW tbcr_tt 

Das Timer C Control Register 

$fffa9D B %XcccXdddX tacr_tt 
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Das Timer A Data Register 

$fffa9f B %nnnnnnnn RW tadr_tt 

Das Timer B Data Register 

$fffaa1 B %nnnnnnnn RW tbdr_tt 

Das Timer C Data Register 

$fffaa1 B %nnnnnnnn RW tcdr_tt 

Das Timer D Data Register 

$fffaa1 B %nnnnnnnn RW tddr_tt 


3.2.3 Die Vektortabelle der MFP’s 

Eine Vektortabelle ist eine Liste im Speicher mit lauter Langwör¬ 
tern, diese Langwörter stehen für Adressen. Diese Adressen wer¬ 
den vom MFP gebraucht, da er dem Prozessor eine Vektornummer 
sendet, der wiederum erzeugt aus der Vektornummer eine Adres¬ 
se, in dem er aus der Vektortabelle das Langwort an der Stelle 
Vektornummer*4 herausholt. Diese Adresse wird angesprungen 
und hoffentlich eine Interruptroutine ausgeführt. Das passiert aller¬ 
dings nur, wenn der Interrupt nicht im ’imra’ maskiert wurde. 
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Die ST - MFP Vektortabelle 

Adresse Nummer Status Verwendung 


niedrigste Priorität 


$100 

0 

maskiert 

Centronics BUSY 

$104 

1 

maskiert 

DCD serielle Schnitt. 

$108 

2 

maskiert 

CTS serielle Schnitt. 

$10c 

3 

maskiert 

GPU Done - Blitter 

$110 

4 

maskiert 

Baudr. Gen. ser. Schnitt. (Timer D) 

$114 

5 

aktiv. 

200 Hz Timer (Timer C) 

$118 

6 

aktiv. 

1 KBD/MIDI ACIA’s 

$11c 

7 

maskiert 

FDC/ASCI DMA - Bus Steuerung 

$120 

8 

maskiert 

Display Enable (Timer B) 

$124 

9 

aktiv. 

Sendefehler, ser. Schnitt. 

$128 

10 

aktiv. 

Sendepuffer leer, ser. Schnitt. 

$12c 

11 

aktiv. 

Empfangsfehler, ser. Schnitt. 

$130 

12 

aktiv. 

Empfangspuffer voll, ser. Schnitt. 

$134 

13 

maskiert 

unbenutzt 

$138 

14 

maskiert 

Ring Indicator, ser. Schnitt 

$13c 

15 

maskiert 

Monochrome detect 


höchste Priorität 
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Die TT - MFP Vektortabelle 

Adresse Nummer Status Verwendung 
niedrigste Priorität 


$140 

0 

maskiert 

I/O Pin 1, J602 Motherboard 

$144 

1 

maskiert 

I/O Pin 3, J602 Motherboard 

$148 

2 

maskiert 

XDMAIRQ SCO DMA 

$14c 

3 

maskiert 

XBRIQ Ring Inicator, Modem 2 

$150 

4 

maskiert 

Baudrate Serial 1 (Timer D) 

$154 

5 

maskiert 

TCCLK - Takt an SCO (Timer C) 

$158 

6 

maskiert 

DCH (Drive Ready) int Floppy 

$15c 

7 

maskiert 

XSDMAIRG von SCSI DMA 

$160 

8 

maskiert 

Display Enable (Timer B) 

$164 

9 

aktiv. 

Sendefehler, ser. Schnitt. TT 

$168 

10 

aktiv. 

Sendepuffer leer, ser. Schnitt. TT 

$16c 

11 

aktiv. 

Empfangsfehler, ser. Schnitt. TT 

$170 

12 

aktiv. 

Empf.puff. voll, ser. Schnitt. TT 

$174 

13 

maskiert 

unbenutzt 

$178 

14 

maskiert 

TT Uhrenchip 

$17c 

15 

maskiert 

SCSI DMA 


höchste Priorität 
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3.2.4 Betriebssystem-Routinen zum Programmieren des MFP 

Hier nur die, die man zum Installieren einer eigenen Interruptroutine 
benötigt. Achtung, diese Aufrufe funktionieren nur für den ST - 
MFP. 

Nomenklatur: BYTE = 8 Bit 

WORD = 16 Bit 
LONG = 32 Bit 

VOID = Dummy, d.h. keine Rückgabe 
* = Zeiger auf 

Rückgabe erfolgt in DO 

Beispiel: 

XBIOS31 

VOID Xbtimer(WORD timer, WORD control, WORD data, LONG *vec) 
ist 


pea 

vec 

move.w 

#data,-(sp) 

move.w 

#control,-(sp) 

move.w 

#timer,-(sp) 

move.w 

#31 ,-(sp) 

trap 

#14 

lea 

12(sp),sp 


XBIOS 26 

VOID Jdisint(WORD into) 

Mit diesem Aufruf ist es möglich, je einen Interrupt des MFP zu 
sperren. 

into, Nummer des zu sperrenden Interrupts 0..15 (siehe 4.2.3) 
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XBIOS 13 

VOID Mfpint(WORD interno, LONG *vektor) 

Setzt den Vektor z.B einer eigenen Routine in der Vektor Tabelle. 

interno, Nummer des zu überschreibenden Vektors (0 bis 15) 
vektor , der zu setzende Vektor 


XBIOS 27 

VOID Jenabit(WORD into) 

Damit kann man einen Interrupt des MFP wieder zulassen, 
into, Nummer des zu ermöglichenden Interrupts (0 bis 15) 


XBIOS 31 

VOID Xbtimer(WORD timer, WORD control, WORD data, LONG *vec) 

Diese Funktion installiert einen Timer Vektor, es wird dabei ’vec’ in 
die Vektor-Tabelle geschrieben, das entsprechende Bit im Interrupt 
Enable und Interrupt Mask Register gesetzt. 

timer , Nummer des Timers (0..3 = A..D) 

control , setzt das Timer Control Register 

data , setzt Timer Data Register 

vec , Routine, die bei Interrupt aufgerufen werden soll 
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3.2.5 Installieren einer MFP Interruptroutine 

Dazu gibt es zwei Möglichkeiten: Einmal mittels des Betriebssy¬ 
stems und zum anderen durch direktes Schreiben der Interrupt¬ 
adresse in die Vektortabelle und Zulassen des jeweiligen Interrupts 
in der Interruptmaske. Das Betriebssystem macht das zwar auch 
nicht anders, wie wenn man’s per Hand in die Register schreibt, 
aber die Hardware des ATARI’s ist keine Konstante, d.h. jedes 
neue Modell (siehe Falcon030) hat so seine Änderungen, die das 
Betriebssystem natürlich berücksichtigt (meistens). Andererseits 
gibt es keine Betriebssystem-Aufrufe, um eine Interruptroutine für 
den TT MFP zu installieren, also zeige ich beide Möglichkeiten ei¬ 
ner Installation. 

Installation eines Timer Interrupts via Betriebssystem: 


pea interrupt(PC) 

move.w #170,-(SP) 

move.w #8,-(SP) 

move.w #1,-(SP) 

move.w #31 ,-(SP) 

trap #14 

lea 12(SP),SP 


;eigener Vektor auf Stack 
; 170 in Data Register 
;EVENT COUNT 
;TIMER B 
;Xbtimer 
;XBIOS Aufruf 
;Stack zurück 


Installation eines Timer Interrupts "per Hand": 


pea 

Install(PC) 

;Adresse der Installations- 



;Routine 

move.w 

#38,-(SP) 

;Superexec 

trap 

#14 

;XBIOS Aufruf 

addq.l 

#6,SP 

;Stack zurücksetzen 


Install: 


lea 

interrupt(PC),AO 

;Interruptvektor in A0 

move.l 

A0,$120.w 


bset 

#0,$FFFFFA07.w 

;lnt. Enable A, Timer B zulassen 

bset 

#0,$FFFFFA13.w 

;lnt. Mask A, Maskierung aufheben 

move.b 

#170,$FFFFFA21.w 

; 170 in Data Register 

move.b 

rts 

#8,$FFFFFA1 B.w 

; EVE NT COUNT, Timer A Ctrl. Reg. 
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Beide Programmteile installieren eine Interruptroutine für den Timer 
B Interrupt und stellen den Timer in den EVENT COUNT (Zähle 
Ereignis) mode. Da zählt der Timer B kräftig die Display Enable 
(DE) Signale, die immer dann kommen (HIGH - 5V), wenn eine 
neue Zeile dargestellt wird. An den Rändern, wo der Monitor 
schwarz ist, wird das DE Signal LOW (OV). Nun ist das Bit 3 (Bit 4 
für Timer A und Busy an der seriellen Schnittstelle) des Active Ed- 
ge Register schon von vornherein so eingestellt (gelöscht), daß bei 
einem Pegelwechsel von High auf Low ein Interrupt ausgelöst wird, 
so daß der Interrupt am Ende der in Timer B Data Register ange¬ 
gebenen Zeile -1 schon ausgelöst wird, man sich im Zeilenrücklauf 
befindet. Wenn nun keine anderen Interrupts dazwischenfunken, 
was sie (wenn man sie nicht abschaltet) aber immer tun, kann man 
während des Zeilen-Rücklaufs z.B die Hintergrundfarbe ändern und 
so in jeder Zeile eine andere Hintergrundfarbe zeigen. 

Nun noch das Aussehen einer MFP Interruptroutine: 

interrupt: 

; hier folgt jetzt die auszuführende Routine 
; bitte vergessen sie nicht die benutzten 
; Register (z.B. auf den Stack) zu retten !!! 

; und vor Beendigung wieder zurückzuschreiben !!! 
bclr #0,$fffffA0F.w ; nur falls Software End of Interrupt 

rte ; Return from Exception !!! 

Eine jede Interruptroutine (nicht nur die vom MFP ausgelösten) 
wird mit einem ’RTE’ beendet. Das entsprechende Bit (hier Bit 0 / 
Timer B) im Interrupt in Sevice Bit muß nur dann zurückgesetzt 
werden, wenn sich der MFP im Software End of Interrupt, die 
Grundeinstellung nach dem RESET, befindet; dies läßt sich aber 
mit Bit 3 des Vektor-Registers ändern. 
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3.3 Abfragen der Joysticks 

Da die Joystickdaten der “alten" Ports über den IKBD laufen und 
dieser einen Interrupt über den MFP auslöst, wenn ein Datenpaket 
am ACIA anliegt, habe ich mich entschieden, das Thema Joystick 
in diesem Kapitel zu behandeln. 


3.3.1 Abfragen der ST kompatiblen Joystickports 

Dies erfolgt durch die Programmierung des IKBD, der muß erst 
mal so eingestellt werden, daß er Joysticksignale sendet ! Um über 
das Betriebssystem mit dem IKBD direkt kommunizieren zu kön¬ 
nen, gibt es zwei Möglichkeiten ! 

BIOS 3 

void Bconout(WORD dev, WORD c) 

Gibt Zeichen an ein Ausgabegerät aus. 

dev, Nummer des Gerätes 

0 = parallele Schnittstelle (PRT) 

1 = serielle Schnittstelle (AUX) 

2 = VT 52 Konsole (CON) 

3 = MIDI Schnittstelle (MIDI) 

4 = Tastatur Prozessor (IKBD) 

5 = Konsole ohne VT52 (RAWCON) 

c , ist das auszugebende Zeichen 

XBIOS 25 

void lkbdws(Word ent, WORD LONG *ptr) 

Überträgt eine Zeichenkette zum IKBD 

ent, Menge der zu übertragenen Zeichen -1 

ptr, Zeiger auf die zu übertragende Zeichenkette 
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IKBD auf Joystick Meldungen stellen 


move.w 

#$14,-(SP) 

;IKBD Jystick 

move.w 

#4,-(SP) 

;Ziel IKBD 

move.w 

#3,-(SP) 

jbconout 

trap 

#13 

;bios 

addq.l 

#6,SP 



Nun ist das Betriebssystem eigentlich schon für Joystickereignisse 
ausgelegt, die entsprechenden Pakete werden von den ACIAs ab¬ 
geholt und irgendwo zwischengespeichert. Allerdings existiert im 
Betriebssytem keine Routine, die die Joystickdaten verarbeitet. Es 
gibt aber eine Sprungtabelle in der für jedes IKBD-Ereignis eine 
Adresse steht, die Routine in dieser Tabell für die Joystickverar¬ 
beitung zeigt jedoch auf ein ’RTS’ (ReTurn from Subroutine), was 
soviel bedeutet wir "geh zurück von wo du gekommen bist". Aber 
das ist kein Problem, wir installieren einfach unsere eigene Routi¬ 
ne. Dazu brauchen wir allerdings die Adresse der Vektortabelle und 
dafür gibt es natürlich auch einen Betriebssystem-Aufruf. 

XBIOS 34 

LONG Kbdvbase() 

gibt Adresse einer Vektortabelle zurück, 
die so aussieht: 

LONG Adresse von MIDI Eingaberoutine 
LONG Adresse von Tastatur Error 
LONG Adresse von MIDI Error 
LONG Adresse von IKBD Status 
LONG Adresse von Mausabfrage 
LONG Adresse von Uhrzeitabfrage 
LONG Adresse von Joystickabfrage !!! 

LONG Adresse von MIDI Systemvektor 
LONG Adresse von IKBD Systemvektor 
LONG Adresse von IKBD Treiberstatus 

Man ersetze nun die Joystickroutine des Betriebssystem durch ei¬ 
ne eigene und hole sich die Joystickdaten in einen Speicherbereich, 
den die eigene Joystickroutine in AO gemeldet bekommt, 
das sieht dann so aus 
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lea 

joyl (PC),Al 

; Adresse wo Daten 
;abgelegt werden 

adda.w 

#1 ,A0 

;Kennbyte überspringen 

move.b 

(A0)+,(A1)+ 

;Kopieren in Joyl 

move.b 

(A0)+,(A1)+ 

;Kopieren in Joy2 

DS.B 1 
DS.B 1 




im Byte joyl und joyl+1 stehen dann die Joystickdaten in Bit 0 bis 
3, genau so wie man sie von GFA - BASIC her kennt. In Bit 7 be¬ 
findet sich der Status des Schußknopfs, bei gesetztem Bit ist der 
jeweilige Knopf gedrückt. 


Jetzt braucht man den IKBD 
pea befehl(PC) 

move.w #1,-(SP) 
move.w #25,-(SP) 
trap #14 

addq.l #8,SP 


nur wieder zurückzustellen 

;IKBD Befehle 

;Befehle -1 

;lkbdws 

;XBIOS 


befehl: DC.B$15,8 ;Joystick aus 

;relative Maus an 


und den ursprünglichen Joystick-Vektor wieder in die Vektortabelle 
zurückzuschreiben. Natürlich gibt es ein Beispielprogramm in 
"KAPB3.TOS" auf der beiliegenden Diskette. 
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3.3.2 Abfragen 1040 STE kompatiblen Joystickports 

Die haben nun ganz und gar nichts mit dem MFP zu tun, aber was solls. 


Die "neuen" Joystickports sind wesentlich einfacher abzufragen, da 
die Joystickdaten auf jeden Fall an der Adresse anstehen und so¬ 
lange anstehen, bis sich die Stellung des Joystick geändert hat. Bei 
den Paketen des IKBD stehen die Daten nur eine gewisse Zeit in 
den ACIAs und müssen auch alle abgeholt werden, da man sonst 
nicht weiß, um welche Art von Daten (Joysticks, Mouse, Key¬ 
board) es sich handelt; man muß also sofort auf die Interrupts rea¬ 
gieren. Man kann bis zu vier Joysticks, zwei Paddies oder einen 
Light Pen an die neuen Ports anschließen. 

Der Schußknopf 

$ff9200 W %XXXX XXXX XXXX nnnn R BUTTON 

Joystick Ports als Eingang 

Spiegelt die Position der angeschlossenen Joysticks wider. 

$ff9202 W %oulr oulr oulr oulr W JOY 
STICK: 3 1 2 0 

o = oben 
u = unten 
I = links 
r = rechts 

Joystickport als Ausgang 

$ff9202 W %XXXX XXXX aaaa aaaa W JOY 

a = beschreibbare Bits 

Beim Beschreiben dieser Bits liegt an den Ausgängen bei den ge¬ 
setzten Bits ein entsprechender 5V Pegel an. 
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Die Paddels 

$ff9210 W %XXXX XXXX pppp pppp RO XPaddleO 
$ff9212 W %XXXX XXXX pppp pppp RO YPaddleO 

$ff9214 W %XXXX XXXX pppp pppp RO XPaddlel 
$ff9216 W %XXXX XXXX pppp pppp RO YPaddlel 

pppp pppp, Bits zur Darstellung analoger Werte 

Eingang für analoge Joysticks oder Paddies. 


Light - Pen/Gun 

$ff9220 W %XXXX XXpp pppp pppp RO Xlight 
$ff9222 W %XXXX XXpp pppp pppp RO Ylight 

Genauigkeit X, 16/Menge der Planes (Falcon ???) 

Y, Zeilenweise 

Um den genauen X-Wert zu erreichen, muß der Pixel Wert mit ei¬ 
nem Faktor multipliziert werden. 

Faktor: 16/4*Anzahl der Planes (Falcon ???) 

Nun hat es ATARI leider verpaßt, in alle neuen Rechner diese neu¬ 
en Joystickbuchsen einzubauen, so sind zwar bei den MEGA 
STE’s intern die Buchsen vorgesehen, aber nicht nach außen ge¬ 
legt worden und auch der TT besitzt keine dieser neuen Anschlüs¬ 
se. Beim Abfragen dieser Ports muß man also erst mal nachfra- 
gen, ob überhaupt welche vorhanden sind. Das kann man zum ei¬ 
nem durch Abfragen des Rechnertyps in den Cookies machen und 
zum anderen durch Abfragen der entsprechenden Register und Ab¬ 
fangen des Bus-Fehlers bei Nichtvorhandensein der Buchsen. Bei¬ 
des birgt einige Probleme in sich, zum einen scheint der TT an der 
Adresse $ff9200 irgend etwas liegen zu haben, so daß man z.B. 
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$ff9202 abfragen müßte und zum anderen weiß man nicht, ob in 
anderen ATARI-Rechnern diese Adressen nicht wieder durch an¬ 
dere Peripherie (wie im TT) belegt wird. Das gleiche Problem tritt 
auch beim Testen des Rechnertyps per Cookies auf. Ich kann zum 
einen auf FalconOßO und 1040 STE testen und inoriere kommende 
Rechnertypen, die möglicherweise auch die neuen Ports besitzen 
oder ich teste auf 1040 STE und alle Rechener größer als 
Falcon030 und der Falcon040 (hoffentlich kommt er bald) hat viel¬ 
leicht gar keine "neuen" Joystickports (wie der TT) mehr. 

Nun, wenn ich mich erst einmal entschieden habe, daß der Rech¬ 
ner, auf dem das Spiel läuft, diese Joystickports besitzt, ist die Ab¬ 
frage kein Problem, einfach im Supervisormode die Speicherstelle 
in ein Register und den Inhalt testen. 
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B.4. Sounderzeugung auf den Atari Rechnern 

Die Rechner der Atari ST/STE/TT (Falcon ausgenommen) Serie 
sind lange nicht so flexibel in der Sounderzeugung wie z.B. der 
AMIGA oder die meisten Soundkarten auf dem PC. Es ist dennoch 
möglich, mit entsprechendem Knowhow erlesene Soundeffekte die¬ 
sen Rechnern zu entlocken. 


4.1 Grundlagen der Tonerzeugung 

4.1.1 Das Wesen der Töne und Geräusche 

Töne und Geräusche sind Luftschwingungen. Ähnlich wie man im 
Wasser Wellenbewegungen z.B. durch Paddeln erzeugen kann, 
kann man mit einer Stimmgabel die Luft in Schwingungen verset¬ 
zen. Und ähnlich wie der Seetang am Strand des Meeres von den 
Wellen hin und her bewegt wird, werden in unsere Ohren kleine 
Härchen angeregt, mit den Luftwellen zu schwingen. Diese 
Schwingungen werden dann von Nerven an unser Hirn weitergelei¬ 
tet und in das umgewandelt, was wir letztendlich hören (das Hirn 
fungiert dabei wohl als so ’ne Art A/D Wandler ?!). Es gibt also 
Druck-und Unterdruck-Gebiete, die durch die Schallwellen erzeugt 
werden. 

Wenn zwei Wellen sich treffen, die zum selben Zeitpunkt Druck und 
Unterdrück haben, verdoppelt sich der Druck bzw. Unterdrück den 
sie in der Luft erzeugen. Sind zwei Wellen aber gegenläufig, d.h. 
auf Druck der einen folgt der Unterdrück der anderen, löschen sie 
sich aus. In einem Lautsprecher werden Wechselströme, die wahr¬ 
scheinlich auch nichts anderes sind als Schwingungen in den Elek¬ 
tronenwolken des Leiters (z.B. Kupferdraht), somit ähnlich geartet 
sind wie die Wellen, die wir in Luft (Schall) und Wasser kennen, in 
Schallwellen umgewandelt. Bei einem normalen ST (ohne E) wer¬ 
den die Wechselströme für den Lautsprecher von einem ärmlichen 
Chip erzeugt, der nur höchstens drei Rechteckwellen und ein Rau¬ 
schen hervorbringt. Nun wäre dies schon Stereo (!), wenn es Atari 
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nicht vorgezogen hätte, alle Tonausgänge zusammenzuschalten. 
Aber dies ist schon lange her und neuere Geräte haben tatsächlich 
(viele Jahre nach dem Erscheinen des Amiga) Stereoausgänge. 


4.1.2 Kleine Nomenklatur der Sample/Synthesizertechnik 

In vielen Programmen werden Ausdrücke wie LFOA/ibrato, Filter, 
Abspieffrequenzen, Samplingrate ... u.v.m gebraucht. Der "stereo¬ 
type" Computerfreak, der mit seinem Atari Musik macht und Syn¬ 
thesizer so schnell und so gut wie seinen Radiowecker program¬ 
mieren kann, weiß natürlich, was die Ausdrücke zu bedeuten ha¬ 
ben. Für alle anderen biete ich dieses Kapitel an. 

Amplitude - Lautstärke 

Je größer die Auslenkung der Wellen wird, desto lauter sind diese. 

Filter 

Analoge Filter sind Widerstands/Kondensator Glieder, die nur be¬ 
stimmte Frequenzen durchlassen. Digitale Filter sind dessen rech¬ 
nerische Nachbildung. Mit digitalen Filtern kann man auch Baustei¬ 
ne erzeugen, die in der Realität nicht möglich sind. Zum Erzeugen 
solcher digitaler Filter eigenet sich z.B. ein Digitaler Signal Prozes¬ 
sor (z.B DSP 56001), wie er im Falcon eingebaut ist, recht gut. 
Meist unterscheidet man zwischen zwei Arten von Filtern: Hoch- 
und Tiefpaß-Filter. Wie schon der Name sagt, läßt die eine Sorte 
von Filtern hohe Frequenzen ungehindert passieren (Hochpaß) und 
dämpft die Tiefen beim Tiefpass. Der Tiefpaß verhält sich genau 
umgekehrt.Nun, bei Geräuschen ist das vielleicht noch verständ¬ 
lich, aber ein Ton hat doch nur eine Frequenz ? 

Man kann einen Ton aus vielen Sinuswellen zusammensetzen, den 
sogenannten Harmonischen (man nennt diese Technik Fourier¬ 
transformation). Jede dieser Sinuswellen hat eine andere Frequenz 
und Lautstärke, wenn man also unendlich viele Sinuswellen hat, die 


222 



Sounderzeuauna auf den Atari Rechnern 


sowohl in Frequenz als auch in ihrer Amplitude wechseln dürfen, 
kann man jedes beliebige Geräusch erzeugen. Einige Synthhesizer 
funktionieren nach diesem System, man nennt dies additive Syn¬ 
these (sehr schwer zu programmieren). 

Filter dämpfen bei allen Wellenformen (außer Sinus) diejenigen Si¬ 
nuswellen aus denen sie bestehen, die eine bestimmte Frequenz je 
nach Filtertyp übersteigen oder unterschreiten. Analoge Filter ha¬ 
ben grundsätzlich eine bestimmte Flankensteilheit, d.h. sie setzen 
bei bestimmten Frequenzen langsam ein und haben in einem ge¬ 
wissen Bereich die volle Wirkung. Die Wirkung von digitalen Filtern 
hängt von deren Rechentiefe ab, je tiefer der Prozessor rechnet, 
desto näher kommt er dem idealen Filter (es gibt in der Theorie ei¬ 
nen idealen Filter, der optimale Ergebnisse liefert. Durch die Tole¬ 
ranzen der Bausteine bei den analogen und der begrenzten Re¬ 
chentiefe bei digitalen Filtern, ist der ideale Filter nur in der Theorie 
möglich.). 

Resonanz 

Nennt man bei synthetischer Tonerzeugung die Rückkoppelung des 
Filters, dabei wird der Frequenzbereich des Tons angehoben, der 
an der Grenzfrequenz (CUT OFF) des Filters liegt. Bei vielen Syn¬ 
thesizern lassen sich Grenzfrequenz und Stärke der Rückkoppe¬ 
lung regeln. 

Im eigentlichen Sinne ist Resonanz das Mitschwingen und gleich¬ 
zeitige Aufschaukeln (Verstärken) von Wellen. Zum Beispiel über¬ 
quert eine Gruppe von Menschen im Gleichschritt eine Brücke. Die 
Brücke wird in Schwingung versetzt, und wenn das Schwingen der 
Brücke mit dem Auftreffen der Füße immer wieder zusammentrifft 
(das ist die Resonanzfrequenz), ist das eine Art von Resonanz. 
Die Brücke wird in immer stärkere Schwingungen versetzt und 
kann unter Umständen einstürzen. Wenn eine Saite an einer aku¬ 
stischen Gitarre gezupft wird, schwingt sie und setzt das Gehäuse 
(Körper) der Gitarre in Schwingungen. Auch das ist Resonanz, 
denn der Klang der Saite wind ja verstärkt. 
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Sampling bzw. Digitalisieren im Audio (Ton) Bereich 

Als Sampler bezeichnet man im professionellen Musikbereich Ge¬ 
räte, die mittels eines A-D-Wandlers analoge Ton Signale (also so, 
wie sie in der Natur Vorkommen) in digitale (so wie sie der Rech¬ 
ner versteht, im Prinzip 1 und 0) verwandeln und speichern, und 
diese dann meist mehrstimmig und in unterschiedlichen Frequen¬ 
zen (Tonhöhen) wieder abspielen können. Diese Geräte sind aller¬ 
dings immer noch relativ teuer aber liefern meistens eine exzellente 
Klanqualität d.h. im Bassbereich clean und viel Druck (z.B. für gute 
Bass Drums) und in den Höhen klar und rein (z.B. für Beils) ohne 
Nebengeräusche, kein Zischen und kein "Fipsen". Die meisten 
Rechner kommen bisher an diese Soundqualtität auch nicht annä¬ 
hernd heran, weder Amiga noch irgendwelche gebräuchliche 
Soundkarten für PC’s haben (auch wenn das einige ihrer Besitzer 
glauben) den Frequenzgang, die Dynamik und den S/N (Signal to 
Noise - Rauschabstand) professioneller Geräte ("Da is nix mit ver¬ 
dammt nah an der CD !"). Allerdings geht die Entwicklung (Multi 
Media heißt das Schlagwort) immer mehr in Richtung guter 
Soundqualität, auch für Computer, während der gehobene Audio 
Bereich langsam über den Standard der CD hinauswächst. 

Also weiter! Aus dem analogen Signal werden Nullen und Einsen, 
die dann im Speicher des Gerätes gespeichert werden. Je nach 
A/D (Analog zu Digital) Wandler werden unterschiedliche Pakete 
von Bits (z.B. Bytes oder Worte) an den Rechner geliefert. Je nach 
Bitbreite der Pakete, kann man auch von einem anderen Dynamik¬ 
bereich des Digitizers ausgehen (je höher die Dynamik, desto grö¬ 
ßer ist der Unterschied zwischen lautestem und leisestem reprodu¬ 
zierbarem Geräusch). 
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Beispiel: 8 Bit (STE/TT DMA oder AMIGA) 

256 Lautstärkestufen 

16 Bit (z.B. Falcon030 oder CD) 

65536 Lautstärke-Stufen 

das läßt sich vergleichen mit der vertikalen Auflösung eines Bildes! 
Die Horizontale ist dann die Geschwindigkeit in der der Digitizer 
seine Daten liefert. 

Beispiel: ca. 41 kHz (CD Qualität) bedeutet 

41000 Abtastungen pro Sekunde 

das wiederum bedeutet bei 16 Bit 

82000 Bytes Speicher werden in jeder Sekunde 

gefüllt! 

Als Faustregel gilt, daß die halbe Abtastfrequenz die höchste Fre¬ 
quenz ist, die ein Digitizer aufnehmen kann. Das ist auch irgendwie 
verständlich, da Schwingungen ja aus Änderungen (z.B. des Luft¬ 
drucks) bestehen müssen und zu einer Änderung gehören minde¬ 
stens zwei Werte (ein hoher und ein niedriger Wert). Da der 
Mensch nur eine geringe Bandbreite (ca. 40 Hz bis 20 kHz) hat, ist 
es im Normalfall nicht nötig, eine Abtastfrequenz von 41 kHz zu 
überschreiten. Da man die Dynamik und Abtastrate wegen be¬ 
grenztem Speicher und Rechenzeit, nicht unendlich hoch wählen 
kann, bleiben immer relativ hohe Sprünge in den Lautstärkestufen 
zwischen den einzelnen vom D/A Wandler (wandelt die Bitblöcke in 
Lautstärkestufen um) abzuspielenden Werten. Um diese zu verin- 
gern, kann man entweder die Werte interpolieren und mit einer Art 
Antialiasing versuchen, die Ecken des Samples abzurunden (digita¬ 
ler Filter u. ähnl.) oder das analoge Ausgangssignal mit Filterstufen 
ein bißchen abrunden (oder beides). 

Wer sich selbst einen A/D Wandler bauen möchte, um die Sounds 
in seinen eigenen Spielen zu verwenden, dem empfehle ich in fol¬ 
genden Ausgaben folgender Computerzeitungen nachzulesen. 
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Bauanleitungen in: 

ST Computer Nr.6 Juni 92, Stereo Sampler für den TT 
(auch für ST’s und STE’s zu gebrauchen) 

ST Computer Nr.7/8 August/September 88, 

Samples mir’s noch einmal Sam 

ST EXTRA 3, Das Profiline System 

68000er Sonderheft 9, Atari ST als Tonstudio 

diese Liste hat keinen Anspruch auf Vollständigkeit und enthält nur 
die mir bekannten Ausgaben. 

Abkürzungen, die in verschiedenen Synthesizern und Musikpro¬ 
grammen benutzt werden, um die Funktionen anzuwählen: 

VC steht immer für Voltage Controlled d.h kontrolliert durch die 
Spannung. 

DC steht für Digital Controlled d.h. gesteuert durch einen Prozes¬ 
sor. 

VCF DCF = Regelung des Filters 

VCA DCA = Regelung der Amplitude (Lautstärke) 

VCO DCO = Regelung der Frequenz 

LFO oder Vibrato = Regelung der Tonhöhe über einen zusätzli¬ 
chen Oszillator meist mit den Wellenformen 
Dreieck, Rechteck, Sinus, Zufall, erzeugt z.B 
Effekte wie das Heulen von Sirenen oder die 
klirrenden Sounds in den Sound - Demos etc. 
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Envelope, Hüllkurve = mit diesen Parametern läßt sich der Laut¬ 
stärkenverlauf eines Klangs steuern, z.B. 
der Sound wird ganz langsam lauter und 
hört dann abrupt auf oder ist sofort da und 
klingt langsam aus etc. meist sind Parame¬ 
ter wie Lautstärke und Zeit in verschiedenen 
Stufen einzustellen. 


4.1.3 Soundsynthese 

Es ist, wie schon oben erwähnt, möglich, Sounds per Digitizer von 
außen in den Computer zu befördern. Es ist allerdings auch mög¬ 
lich, Synthesizer zu simulieren und somit die benötigten Sounds, 
quasi per Hand, einzugeben. 

Die Synthesearten, die ich kurz erklären möchte, sind: 

ANALOG - gebräuchlich in Geräten wie MINI MOG, 

Prophet T800, u.v.m. 

FM - Frequenzmodulation, gebräuchlich unter anderem in 

Yamaha Synthesizern. 

PD - Phase Distortion (Phase Verzerrung), gebräuchlich in 

Casio Synthesizern. 

RM - Ring-Modulation, wird bei vielen Synthesizern zusätz¬ 

lich angeboten. 

AS - Additive Synthese (Fourier Synthese) 
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4.1.3.1 Analoge Tonerzeugung 

Die allerersten Synthesizer bestanden aus Schwingkreisen als Os¬ 
zillatoren und RC-(Widerstand, Kondensator) Gliedern als Filter. 
Da die Bausteine dieser Geräte wärmer wurden, verschoben sich 
ihre Werte, z.B. wurde der Widerstand kleiner. So ergab sich der 
schon bekannte "lebendige" Klang dieser Geräte. 

Nun kann man diesen lebendigen Klang schlecht simulieren, aber 
man kann Oszillatoren simulieren, indem man Tabellen mit unter¬ 
schiedlichen Wellenformen ausliest und an den D/A Wandler über¬ 
gibt. Ähnlich läßt sich ein Filter simulieren, man muß im Prinzip nur 
die resultierenden Wellenformen für jede Filterstellung zuvor in Ta¬ 
bellen abgespeichert haben und je nach Filterstellung die entspre¬ 
chende Tabelle auslesen und an den D/A Wandler übertragen. 
Wenn man die Abspielfrequenz erhöhen möchte, liest man nicht je¬ 
den Wert sondern z.B. jeden zweiten Wert aus der Tabelle und 
schon hat man die doppelte Frequenz und ist bei einer Oktave hö¬ 
her angelangt. 


4.1.3.2 Frequenz-Modulation 

Auf diese Technik hat Yamaha das Patent, auch sie ließe sich mit 
analogen Bausteinen realisieren, mir ist jedoch kein Gerät bekannt, 
das analoge FM benutzt. Die ersten FM Geräte von Yamaha DX 
1/5/7/9/21 und einige Expander (bis TX 81 Z) benutzten 8 Bit D/A 
Wandler und hatten die für den Hobbymusiker nur schwer in den 
Griff zu bekommende Rauschfahne. Bei allen folgenden Geräten 
hat der D/A Wandler mindestens 14 Bit (z.B. DX 7 II oder eben TX 
81 Z und DX 11). Diese Geräte läuteten eine neue Ära in der Syn¬ 
thesizer-Technik ein und veränderten das Gesicht der POP/Techno 
Musik. 

Nun die Technik ! "Analog" ließe sie sich in etwa so realisieren, 
man schließt einen Sinus-Generator mit an den Frequenzeingang 
eines anderen Sinusgenerators an, so daß die Amplitude des einen 
zur Frequenz des anderen addiert wird. Da allerdings der Sinus 
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sich kontinuierlich ändert und man natürlich die Frequenz beider 
Oszillatoren getrennt ändern kann, erhält man am zweiten Oszilla¬ 
tor natürlich keinen Sinus mehr. Das läßt sich natürlich auch mit 
mehr als nur zwei Oszillatoren bewerkstelligen, und die Lautstärke 
der Oszillatoren läßt sich kontinuierlich regeln, um einen dynami¬ 
schen Obertonverlauf (Sinusschwingungen die über der Grundfre¬ 
quenz liegen) zu bekommen. 

Mathematische Formel zur FM für zwei Sinus-Kurven: 
sin(5*sin(2x)) 

Näheres zur FM in dem Buch: 

"FM Theory & Applications: By Musicians for Musicians" von Dr. 
John Chowning und David Bristow, 1986 von der Yamaha Stiftung 
veröffentlicht. 

Wie läßt sich so etwas auf dem Computer realisieren ? 

Nun ja, wie immer digital ! Man nehme eine Tabelle von Sinuswer¬ 
ten (übrigens, das geht auch mit anderen Wellenformen !) lese 
Werte heraus und addiere sie zur Frequenz (Geschwindigkeit), mit 
der man die Sinuswerte aus einer Sinustabelle liest und immer so 
weiter (HAHA! rekursiv), je öfter man das macht desto komplexer 
wird die Wellenform. Die Tabelle mit der Wellenform (z.B. Sinus) 
besteht je nach verwendetem D/A Wandler aus 8 oder 16 Bit Wer¬ 
ten und je nach Format, das der D/A Wandler schluckt, sind diese 
signed/unsigned. 


4.1 .3.3 Phase Disortion (Phasenverzerrung) 

Diese Technik wird in den Casio Synthesizern der CZ/VZ Serie 
verwendet. In den Anleitungsheften der Geräte wird die PD Soun¬ 
derzeugung sehr anschaulich erklärt. Sie beruht im Prinzip auf dem 
Auslesen von Sinus- oder Cosinus-Wellen aus dem Speicher mit 
wechselnder Geschwindigkeit. Dadurch erhält man unterschied- 
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liehe Wellenformen. Der Vorteil dieser Art der Soundsynthese be¬ 
steht darin, daß man keine Filter mehr berechnen muß, da man die 
Verringerung der Unterschiede in der Lesegeschwindigkeit, dem 
Sinus bzw. Cosinus immer näher kommt und somit einen Ton mit 
weniger Obertönen erhält. Natürlich kann man den Unterschied 
zwischen dieser Art des "Filterns” und einem echten Filter hören, 
da ein echter Filter nur in Verbindung mit Resonanz, wenn die CUT 
OFF Frequenz mit der Grundfrequenz übereinstimmt, Sinus-Wellen 
erzeugen kann. 


4.1.3.4 Ringmodulation 

Diese Art der Soundsynthese wird in vielen Synthesizern zusätz¬ 
lich zu ihrer eigentlichen benutzt. Dabei wird ein Welle erzeugt und 
steuert durch ihren Verlauf die Lautstärke der anderen. Bei zwei 
Sinus-Wellen würde die Formel dafür etwa so aussehen. 

a*sin(s*x)*b*sin(v*x) 

a u. b ist die Lautstärke 
s u. v ist die Frequenz 

Bei vielen Geräten sieht die Formel jedoch so aus: 
a*sin(s*x)*b*sin(v*x)+b*sin(v*x) 

Nun, eine Formel ist zwar immer eindeutig aber für die Nicht-Ma¬ 
thematiker unter uns nicht unbedingt leicht zu verstehen. Im Prinzip 
beruht die Ringmodulation darauf, daß die Wellenform des einen 
Oszillatoren, die Lautstärke des anderen steuert. Bei den alten 
Synthesizern, bei denen man die Oszillatoren mit eigenem Ein- und 
Ausgang hatte, war diese Technik der Soundsynthese mit einem 
zusätzlichen Baustein erledigt, der die Aufgaben eines Wellen-Mul- 
tiplikators und ggfs. Addierers übernahm. Die digitale Version des 
Ringmodulators findet man in vielen Casio- und Roland-Synthesi- 
zem wieder. 
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Auf dem Atari kann man ohne großen Aufwand die Ringmodulation 
selbst ausprobieren, indem man einen Ton auf dem Soundchip 
(PSG.der mit den "tollen" Rechteck-Wellen) abspielen läßt und 
dann die Envelope-Geschwindigkeit auf Werte, die im hörbaren Be¬ 
reich liegen, stellt und auf eine Form stellt, die sich dauernd wie¬ 
derholt. Durch etwas Herumprobieren erreicht man "schnell" ein 
vielfaches der Frequenz des Tones, der somit ringmoduliert wird, 
was wiederum recht interessant klingt. Siehe dazu auch das Listing 
der Abspielroutine für die Musik zu Argon 4. 


4.1.3.5 Additive Synthese 

Wie schon erwähnt, kann man sich jede Wellenform als aus vielen 
Sinuswellen mit unterschiedlicher Frequenz und Amplitude zusam¬ 
mengesetzt vorstellen. Das Zerlegen einer Wellenform in ihre Be¬ 
standteile nennt man Fourieranalyse, das schlagen sie besser in ei¬ 
nem guten Physik-Buch , im ST Magazin 8-10/88 oder in einem 
Buch über Signal Processing nach. Aber was man zerlegen kann, 
kann man meist auch wieder mit dem umgekehrten Verfahren wie¬ 
der hersteilen. Man nehme einige Sinuswellen mit der richtigen 
Frequenz und Amplitude, überlagere sie (bzw. addiere die Sound¬ 
daten, wenn man es numerisch mit dem Rechner löst) und schon 
erhält man eine schöne "neue" Welle. Natürlich beschränkt sich 
das Zusammensetzen auf eine endliche Menge von Sinuswellen, 
was allerdings nicht weiter schlimm ist, da man im Prinzip die Si¬ 
nuswellen (Harmonischen oder Oberwellen ) über einer bestimmten 
Frequenz nicht mehr wahrnimmt und wir machen ja keine Musik für 
Hunde, wenn man allerdings einen natürlichen Klang komplett syn¬ 
thetisieren wollte, benötigte man unendlich viele Sinuswellen ("Ham 
we nich /"). 

Aber grau ist alle Theorie, kommen wir nun zur Realisierung ! 
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4.2 Der PSG (Programmable Sound Generator) 

Als die ersten Atari ST’s 1985 verkauft wurden, war den meisten, 
die auf diesem Gerät Spiele schrieben, noch relativ unklar was aus 
dem Gerät herauszuholen war. Gerade in Sachen Sound hatte man 
Vieles für unmöglich gehalten, was dann doch von irgendeinem 
versierten Programmierer erreicht wurde. Zu Beginn, bis ca. 1987 
dachten die meisten ST-User noch, es wäre unmöglich, digitalisier¬ 
ten Sound abzuspielen und gleichzeitig Grafik zu bewegen. Als 
dann einige Spiele und Demos zeigten, daß es doch möglich ist 
- wer erinnert sich nicht an die LOVE SPY Demo der TNT Crew - 
war der Bann gebrochen und es gab kaum noch Programme ohne. 
Das nächste Problem stellte mehrstimmiges Abspielen digitalisier¬ 
ter Sequenzen dar, da der Amiga mit dem Erscheinen des 500er 
immer mehr Zulauf erhielt und man doch gerne die Spiele mit 
Sound in annähernd Amiga-Qualität spielen wollte. Spätestens, 
nachdem man die Cuddly Demo der Carebears gesehen hatte, war 
klar, daß vierstimmiger Sound mit verschiedenen Abspielfrequen¬ 
zen, trotz des Yamaha- bzw. General Instument- (rechteck-piep- 
senden-minimal) Soundchips aus den Urzeiten der Automaten/ Te¬ 
lespielezeit, erlesene Soundereignisse auf dem ST möglich sind, 
allerdings steht bei angemessener Abspielfrequenz die Maschine 
quasi still. Ach ja, ich darf nicht vergessen, daß gleichzeitig zur 
Kultivierung des digitalen Sounds sich noch einige Programmierer 
darum bemühten fantastische Klänge direkt aus dem Soundchip 
ohne über den Umweg, den PSG als D/A Wandler umzufunktionie¬ 
ren. Als State of the Art in Sachen Soundchip Music, würde ich im 
Moment die Punish your Maschine Demo ansehen, speziell die Mu¬ 
sik in von ELECTRA ist exzellent! 

Um niemand zu kränken, möchte ich noch TEX erwähnen, die mit 
ihren ersten Sound Demos gezeigt haben, was in Sachen Sound¬ 
chip-Musik möglich ist. 
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4.2.1 Die Register des PSG 

Der Zugriff auf den PSG erfolgt nur über zwei Adressen, wobei je 
nach Zugriff, je nach Adresse unterschiedliche Effekte erzielt wer¬ 
den. So daß über den Zugriff auf diese beiden Adressen, eines der 
16 internen Register des PSG angewählt und beschrieben werden 


kann. 



Adresse: 

Label: 

Label: 

$ff 8800 

giread 
beim Lesen 

giselect (4 Bit) 
beim Beschreiben 

Beim Beschreiben dieses Registers wählt man eines der 16 Regi¬ 
ster aus, dessen Inhalt man durch Auslesen des Registers erhält. 

$ff 8802 

giwrite 



Durch Beschreiben dieses Registers schreibt man den Wert in das 
mit ’giselect’ angewählte Register der 16 Register des Sounchips. 
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Interne Register des Soundchips: 


Wird mit ’giselect’ ausgewählt! 


Nr. 

0 

Breite: 

nnnnnnnn 

Per. Dauer 

Low Kanal A 

1 

XXXXnnnn 

Per. Dauer 

High A 

2 

nnnnnnnn 

Per. Dauer 

Low Kanal B 

3 

XXXXnnnn 

Per. Dauer 

High B 

4 

nnnnnnnn 

Per. Dauer 

Low Kanal C 

5 

XXXXnnnn 

Per. Dauer 

High C 

6 

XXXnnnnn 

Per. Dauer 

Rauschen 

7 

nnnnnnnn 

1 1 1 1 1 1 1 1 

MIXER & I/O Port Select 


II 1 1 1 1 1 1 

1 II 1 1 II 1 

Kanal A 

0=AN 1=AUS 


1 1 1 1 1 1 1 

Kanal B 

li n n ii 


1 1 1 1 1 1 

Kanal C 

ii li li li 


Rauschen A . 

Rauschen B . 

Rauschen C . 

I/O Port A (0=Eingang/ 1=Ausgang) 
I/O Port B . 


8 XXXnnnnn Lautst. A unterste 4 Bit 

I 

9 XXXnnnnn . B. 

I 

10 XXXnnnnn . C. 

I 

-0=Envelope an 1 =Envelope aus 

11 nnnnnnnn Perioden Dauer Envelope Low 

12 nnnnnnnn High 

13 XXXXnnnn Form der Hüllkurve 
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I/O Port A 

Disk Seitenwahl, 1=Seite 0 
Drive Select Laufw. A, 0=angewählt 

.. B,” " " " 

RS 232, RTS Leitung 
" ", DTR Leitung 
Cent. Parallelport, Strobe 
Pin 3 Monitor Buchse, frei zur Verfügung 
Selektiert 0=LAN, 1=zus. serielle Schnitt. 

15 nnnnnnnn Drucker Port (Centronics), I/O Port B 

Achtung ! ein undokumentiertes Feature ist, daß die beiden Sound¬ 
chip Register sich nicht nur an den angegebenen Adressen befin¬ 
den, sondern sich ab dieser Stelle noch einige Male wiederholen, 
was es wiederum ermöglicht, gleich mehrere Register des PSG mit 
einem Befehl zu beschreiben. Siehe dazu auch entsprechende 
Routine zum Abspielen von "digitalem Sound" im ersten Teil des 
Buches. 


14 nnnnnnnn 


4.2.2 Programmierung des PSG 

Nähere Beschreibung der Register: 

R0&R1, R2&R3, R4&R5: Tonhöhe 

Jeweils zwei Register ergeben einen 12 Bit Wert, der vom PSG als 
Vorteiler genutzt wird. Da der PSG mit 2MHz getaktet wird und der 
externe Takt, vom Soundchip durch 16 geteilt wird, ergibt sich eine 
Frequenz von 125 kHz, die dann auf den 12 Bit Vorteiler treffen. 
Wenn also der Vorteiler auf dem Wert 100 steht, ergibt sich daraus: 
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125000 Hz/100 = 1250 Hz 
I I I 

I I I_ Frequenz von z.B. Kanal A (1. Stimme) 

I I 

I I_ Vorteiler z.B in R0&R1 für Kanal A 

I 

I_125 khz Grundfrequenz 


R6 : Vorteiler für die Rauschfrequenz 

Diese ist nur 6 Bit breit, was wiederum bedeutet, daß man das 
Rauschen nicht so fein einstellen kann; dies ist auch nicht unbe¬ 
dingt nötig. Das Rauschen wird durch ein Rechtecksignal mit "zu¬ 
fälliger" Pulsweite erzeugt, d.h. daß die Impulse des Rechtecks, 
unterschiedlich lang high bzw. low sind, wenn das Muster dieser 
high/low Signale für das Ohr nicht erkennbar ist, nimmt das Ohr 
den Ton als Rauschen wahr. 

R7 : MIXER und I/O 

(Belegung der Bits siehe 4.2.1) 

Der Mixer ermöglicht es, den Rauschgenerator zu den einzelnen 
Tonkanälen dazuzumischen, die Tonkanäle ein- und auszuschalten 
und die I/O Ports des z.B für das Centronics Interface als Ein¬ 
oder Ausgang zu schalten. Wenn man den Centronics Prort als 
Eingang schaltet, kann man z.B. einen A/D Wandler anschließen 
und die Daten kontinuierlich von einer Interruptroutine (z.B. im Ti¬ 
mer A) abfragen lassen. Als Ausgang programmiert, kann man an 
den Centronics Port einen D/A Wandler anschließen, was bei ent¬ 
sprechend gutem D/A Wandler guten Sound bedeutet, da man den 
I/O Port Ausgang in einem Rutsch beschreiben kann und die Laut¬ 
stärke des Samples nicht in ein für den Soundchip verträgliches 
Format bringen muß, kann man dabei sogar noch etwas Rechen¬ 
zeit sparen. Die Bauteilkosten eines einfachen D/A Wandlers, den 
man an den Centronics Port schließen kann betragen ca. DM 12,-. 
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R8, R9, RIO : Lautstärke für die Tonkanäle 

Die ersten 4 Bit sind für die Lautstärke je Kanal verantwortlich, das 
sind 16 Lautstärkestufen, die leider logarithmisch geordnet sind, 
was das Benutzen des PSG als D/A Wandler etwas erschwert. 
Trotzdem gibt es mittlerweile einige gute 8 Bit Tabellen, die es er¬ 
möglichen, recht guten Sound beim Abspielen der Samples aus 
dem PSG herauszuholen, trotzdem macht sich in diesem Fall das 
Fehlen eines Filters durch leichtes Klirren bemerkbar. 

Wenn das 5. Bit in einem der Register gesetzt wird, werden die un¬ 
tersten 4 Bit ignoriert, und die Lautstärke von der Hüllkurve ge¬ 
steuert. Leider gibt es nur einen Hüllkurven-Generator, so daß bei 
gesetztem 5. Bit bei allen drei Soundkanälen alle drei immer gleich¬ 
zeitig spielen, sofern sie im Mixer - Register angeschaltet worden 
sind. 


RI 1&R12 : Periodendauer der Hüllkurve 

Das sind zwei 8 Bit Register also 16 Bit, die als Vorteiler für die 
Geschwindigkeit des Hüllkurvenverlaufs genutzt werden. Ein¬ 
gangsfrequenz ist 2 MHz/ 256, was also 16 mal (!) niedriger ist als 
die Frequenz, die am Vorteiler für die Tonfrequenz anliegt; das muß 
man beachten, wenn man die Hüllkurve zur Ringmodulation ge¬ 
braucht. Bei einer Einstellung von 100: 

7,8125 khz /100 = 78,125 Hz 
I I I 

I I I_ Ausgangsfrequenz 

I I 

I I_ Vorteiler 

I 

I_ Grundfrequenz 

Das zeigt, daß es bei hohen Tönen Probleme bereitet, den Hüllkur¬ 
ven-Generator für die Ringmodulation zu gebrauchen. 
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RI3 : Form der Hüllkurve 


Wenn im Register für die Lautstärke das 5. Bit gesetzt wird, wird 
die hier angewählte Hüllkurve verwendet. Bei Verwendung der 
Hüllkurve zur Ringmodulation, wählt man mit RI 3 die Wellenform, 
die zur Ringmodulation genutzt wird. 


HUlIkuruen 


0 

4 



12 AAAA 

13 / 


® KNN 


9 r\_ 15/1 

10 |\/\/\ 


i' 


R14&R15 : I/O Port A,B 

Es gehört schon etwas Geschick dazu, mit diesen recht dürftigen 
Möglichkeiten des PSG wohlklingende Musik aus dem Monitorlaut¬ 
sprecher erklingen zu lassen. Was dazu nötig ist, ist das entspre¬ 
chende "know how" zum Thema Tonerzeugung. 

Über die Betriebssystem-Funktionen ’Giaccess’, ’Offgibit’, ’Ongibit’ 
und ’Dosound’ lassen sich die oben genannten Register über das 
Betriebssystem programmieren. 

BYTE = 8 Bit 

WORD = 16 Bit 

LONG = 32 Bit 

VOID = Dummy, d.h. keine Rückgabe 

* = Zeiger auf 
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XBIOS 28 

BYTE Giaccess(WORD data, WORD regno) 

Mit diesem Aufruf kann man auf alle Register des Soundchips 
zugreifen. Also nicht nur Musik machen sondern auch den 
Druckerport oder das Driveselect Signal manipulieren. 

data , Wert der in das Soundchip Register geschrieben wird 
regno, Auswahlen des Register 

Liefert den Inhalt des angewählten Registers zurück 

In Assembler: 


move.w 

regno,-(sp) 

move.w 

data,-(sp) 

move.w 

#1c,-(sp) 

trap 

#14 

addq.l 

#6,-(sp) 


XBIOS 29 

VOID Offgibit(WORD bitno) 

bitno, Nummer des zu löschenden Bits im Port A des PSG 


XBIOS 30 

VOID Ongibit(WORD bitno) 

bitno, Nummer des zu setzenden Bits im Port A des PSG 
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XBIOS 32 

VOID Dosound(LONG *psgstr) 

Führt ein Programm aus, das den PSG programmiert, damit sind 
einfache Musikstücke möglich. Die Befehle werden alle 20 ms aus¬ 
geführt, die Abspielroutine hängt im Systemtimer und ist somit un¬ 
abhängig von der Bildwiederholfrequenz (wie andere Soundrouti¬ 
nen). 

psgstr, besteht aus einem Feld von Befehlen, die so aussehen kön¬ 
nen: 

Format: Befehlsbyte, Datenbytes 

$00 - $0f, Byte 1 (lade in Register) 

Bytes 1, in durch Befehlsbyte angegebenes Register laden 

$80, Byte 1 (lade in Zwischenspeicher) 

Bytes 1, in Zwischenspeicher ablegen 

$81, Byte 1, Byte 2, Byte 3 (Schleife) 

Zwischenspeicher, Anfangswert für Registerinhalt 

Byte 1, Registernummer angeben 

Byte 2, wird vom Registerinhalt abgezogen 

Byte 3, wenn als Registerinhalt erreicht, Beenden der Schleife 

$82-$ff, Byte 1 

Byte 1, Inhalt * 20 ms warten, wenn 0, PSG Programm beenden 
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4.3. Der DMA Sound von STE-TT-Falcon 


Den ersten Hinweis auf das DMA Subsystem konnte man schon in 
den ersten schematischen Zeichnungen über den Aufbau des TT 
finden. Damals (erste mir bekannte Veröffenlichung 1988) wurde 
der Sound Shifter genannt. Das erste Gerät, das mit solch einem 
"Sound Shifter" dann verkauft wurde, war der 1040 STE, allerdings 
im Videoshifter integriert. Im TT ist der Sound Shifter ein einzelner 
Baustein, wahrscheinlich, weil mit der Entwicklung des TT Grafik¬ 
chips schon 1986 begonnen wurde (siehe 68000er Happy Compu¬ 
ter Sonderheft Nr. 9) und der DMA Sound zu dieser Zeit noch nicht 
geplant war. 


4.3.1 Das System des DMA Sounds 

Begriffserklärung: 

DMA = Direct Memory Access = Direkter Speicherzugriff 

Nun, der Sound - Shifter im TT holt sich immer dann die Daten aus 
dem Speicher, wenn der Videoshifter eine Pause macht. Das be¬ 
deutet, daß der Soundshifter während des Zeilenrücklaufs, das ist 
immer dann, wenn der Elektronenstrahl am rechten Ende des Bild¬ 
schirms ist und dann an das linke Ende zurückfährt, seinen 4 Wort 
großen FIFO (first in first out) Speicher füllt, daher. Das macht er 
auf demselben Wege wie der Shifter (aus diesem Grund wurde der 
Sound - Shifter ja auch in den STE’s im Shifter untergebracht) da 
dieser ja während des Zeilenrücklaufs keine Daten benötigt (wird ja 
auch kein Bild dargestellt). Das bremst den Atari nur minimal, so 
daß man 50 Khz Stereo Sound abspielen kann, ohne daß man was 
davon bemerkt. 
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4.3.2 Die Register zum DMA - Sound 

Sound DMA - Control 

$ff 8900 W %XXXX XXXX XXXX XX nn RW sndmactl 

I I 

I I_ DMA - Sound Enable 

I Bit gesetzt = an 

I_Frame Repeat 

Bit gesetzt = Repeat 

Wird das 1 .Bit gesetzt, beginnt die DMA Hardware den Speicher¬ 
bereich, der in den folgenden Registern angegeben wird, abzuspie¬ 
len. 

Wird das 2.Bit gesetzt, so wird der in folgenden Adressen festge¬ 
legte Speicherbereich andauernd wiederholt. 

Meine Erfahrung mit dem FALCON030 hat gezeigt, daß man nur 
das niederwertige Byte (das, in dem die zu setzenden Bits liegen) 
dieses Registers beschreiben sollte oder besser nur die entspre¬ 
chenden Bits setzt, da das höherwertige Byte im F030 Einfluß auf 
den benutzten Interrupt hat, der beim Ende eines abzuspielenden 
Frames ausgelöst wird. 

Der durch folgende Adressen bestimmte Speicherbereich, wird 
nach der von Atari benutzten Nomenklatur (Namensgebung) Frame 
genannt. Wahrscheinlich wird das Wort Frame im Sinne von Rah¬ 
men oder Eingerahmtem gebraucht, da ja der Speicherbereich qua¬ 
si durch die beiden Adressen eingerahmt wird. 
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Frame Startadresse: 

High Byte 

$ff 8902 W %XXXX XXXX OOnn nnnn RW sndbashi 
Mid Byte 

$ff 8904 W %XXXX XXXX nnnn nnnn RW sndbasmi 
low Byte 

$ff 8906 W %XXXX XXXX nnnn nnnn RW sndbaslo 
Hier gibt man die Startadresse des Samples ein ! 

Frame Address Counter: 

High Byte 

$ff 8908 W %XXXX XXXX OOnn nnnn RO sndadrhi 
Mid Byte 

$ff 890a W %XXXX XXXX nnnn nnnn RO sndadrmi 
Low Byte 

$ff 890b W %XXXX XXXX nnnn nnnn RO sndadrlo 

in diesen Registern kann man nachlesen, an welcher Stelle im 
Speicher sich der Soundshifter gerade befindet, ähnlich wie beim 
Video - Address - Counter im ST. 
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Frame Endadresse: 

High Byte 

$ff 890e W %XXXX XXXX OOnn nnnn RW sndendhi 
Mid Byte 

$ff 8910 W %XXXX XXXX nnnn nnnn RW sndendmi 
Low Byte 

$ff 8912 W %XXXX XXXX nnnn nnnn RW sndendlo 

In diese Register muß die Endadresse des Frames+1! angegeben 
werden. Der Abstand zwischen den Frames darf nicht kleiner wer¬ 
den als der 4 Wort große FIFO Cache im Sound - Shifter. 

Sound Mode Control: 

$ff 8920 W %XXXX XXXX nOOOOOnnRW sndmode 

I I I 

I 

I 0(%00) 6258 Hz 

I 1 (%01) 12517 Hz 

I 2 (%10) 25033 Hz 

I 3 (%11) 50066 Hz 

I 

I Abspielfrequenz 
I 

I_%0 = MONO / %1 = Stereo 
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Wenn der Soundchip auf Stereo geschaltet wird, nimmt er vom ge¬ 
lesenen Wort das High Byte für den linken und das Low Byte für 
den rechten Kanal. Das Ausgangssignal des DMA - Soundchips 
wird mittels eines Vier-Stufen-Tiefpass-Filters, dessen Cutoff Fre¬ 
quenz auf 40% der Samplefrequenz geschaltet wird, geglättet. 

Wichtig ! Sowohl Anfang/Endadresse sind gepuffert, d.h. sobald der 
Soundchip begonnen hat, den Sound abzuspielen, kann man die 
Adressen eines neuen Frames (unter Musikern nennt man das Se¬ 
quenz) setzen, der Frame wird dann, sofern man ’sndmactl’ auf re- 
peat (2.Bit setzen) gesetzt hat, beim nächsten Durchgang gespielt. 


4.3.3 Programmierung des DMA - Soundchips 

Generell, ist wichtig zu wissen, daß das Format, das der DMA - 
Soundchip abspielen kann, den Nullpunkt bei "0" hat und nicht bei 
"127" wie es beim Abspielen mit dem PSG üblich ist. 

$80 = -128 = maximale negative Amplitude (Lautstärke) 

$00 = 0 = Nullpunkt 

$7F =+127 = maximale positive Amplitude 

Das Format ist hierbei signed Byte ! 

Nun, es gibt mehrere Möglichkeiten, den DMA Soundchip zu nut¬ 
zen. 


4.3.3.1 Einmal abspielen des Frames 

Das Einfachste ist, Start und Endadresse einer Sequenz in die ent¬ 
sprechenden Register zu schreiben, entsprechende Abspielfre¬ 
quenz, MONO/STEREO zu wählen und dann das ENABLE Bit zu 
setzen, um den Sound zu starten. Der Sample (auch ’n Name für 
Frame) wird dann einmal abgespielt und stoppt. Allerdings ist diese 
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Technik unbrauchbar zum Abspielen ganzer Musikstücke, da diese 
bei brauchbarer Abspielfreqenz eine Unmenge von Speicher brau¬ 
chen. 


4.3.3.2 Abspielen unterschiedlicher Frames mit Timer A 

Wenn der Timer A sich im Event Count Mode befindet und es sich 
um einen STE/TT oder Falcon (sofern die Soundhardware entspre¬ 
chend initialisiert wurde) handelt, dann wird kurz bevor das Sample 
beendet ist, genau dann, wenn der 4 Wort große FIFO Puffer die 
letzten Daten eingelesen hat, ein Interrupt ausgelöst. Natürlich nur, 
wenn das Timer-A-Data-Register auf Null steht, sonst wird der 
Frame so oft wiederholt, bis das Timer A Data Register auf Null 
ist. Somit ist es möglich, Sequenzen mehr als nur einmal abspielen 
zu lassen. Nun, wenn der Interrupt ausgelöst wurde bleibt, je nach 
Abspielfrequenz, nicht mehr viel Zeit, um die Start/Endadresse in 
den Registern des DMA - Soundchips zu erneuern, also sollte man 
dies als allererstes während des Interrupts tun. Man kann sich mit 
dieser Technik eine Liste der Adressen von abzuspielenden Fra¬ 
mes zusammenstellen und zusätzlich eine Liste mit der Anzahl der 
Wiederholungen, und kann diese Listen per Timer A-Interrupt abar¬ 
beiten. Wer es gut machen will, kann auch noch Sprünge zu be¬ 
stimmten Frames einbauen oder ein Repeat für Blöcke von Se¬ 
quenzen. Auf jeden Fall verbraucht diese Technik (bei normal gro¬ 
ßen Frames >20 ms) kaum Rechenzeit, allerdings eine Menge 
Speicher. Der benötigte Speicher hält sich jedoch gegenüber der 
ersten Lösung (4.3.3.1) in Grenzen, da ein Musikstück normaler¬ 
weise so aufgebaut ist, daß z.B. der Refrain mehrmals zu unter¬ 
schiedlichen Zeiten gespielt wird, aber nur einmal im Speicher ge¬ 
halten werden muß. 


4.3.3.3 Abspielen unterschiedlicher Frames ohne Timer A 

Gelegentlich benötigt man den Timer A für alles andere als Musik, 
wenn man dennoch Sequenzen so abspielen möchte, wie es im Ka¬ 
pitel zuvor beschrieben wurde, muß man eine andere Möglichkeit 


246 



Sounderzeuqunq auf den Atari Rechnern 


finden zu erkennen, wann das Ende eines Frames erreicht wurde. 
Eine einfache Möglichkeit ist das Abfragen des 'Sound Enable Bits’ 
(1. Bit) im 'DMA - Control Register", denn wenn es gelöscht ist, ist 
der Sound zu Ende. Das Abfragen dieses Bits erfolgt am besten in 
einem Interrupt der sowieso schon regelmäßig ausgeführt wird, 
z.B. Timer C (System Timer) oder VBL, da "hängt" man sich ent¬ 
weder rein oder trägt sich in die entsprechende Liste ein. Um Ti¬ 
mingschwierigkeiten zu vermeiden, sollte man sich Sequenzen 
aussuchen, die an den Schnittstellen (die Stelle, an der das eine 
Frame an das andere ansetzt) keine Instrumente wie schnelles 
Becken oder sehr kurze Noten spielen, da an diesen Stellen Verän¬ 
derungen im Timing besonders auffallen würden. Am besten sind 
Frames, die in sich abgeschlossen sind. Auch ist es besser, die 
Samples ein bißchen kürzer abzupielen als sie vom Takt her sein 
müßten, um die möglichen Verzögerungen vor dem Aufruf des 
nächsten Frames auszugleichen, denn nichts ist schlimmer für das 
menschliche Rhythmusempfinden, als wenn ein Beat (Rhythmus¬ 
schlag) nachhinkt, er sollte lieber etwas früher kommen. Ein biß¬ 
chen herumprobieren muß man da schon mal! 

Eine andere Möglichkeit um herauszufinden, wann der DMA 
-Soundchip das Ende des Frames erreicht hat, ist durch kontinuier¬ 
liches Testen der Adress - Counter des Soundshifters. Wobei man 
dabei, wenn der Soundshifter im Repeat Modus arbeitet eigentlich 
nach dem Starten der DMA - Soundchips gleich neue Start/End¬ 
adressen in dessen Register schreiben muß und dann nur noch te¬ 
sten muß, wann er die neue Adressen angenommen hat, um dann 
gleich die Adressen des nächsten Frame in die Register zu kopie¬ 
ren. Noch eine Möglichkeit herauszufinden, ob ein Frame zu Ende 
ist, hat man durch das Abfragen des GPIP des MFP ($fffffa01) da 
dort das Monochrome-Detect-Bit (Bit 7) und das Frame End Signal 
mit XOR verknüpft, anliegen. Im Monochrome-Modus (STE/Falcon 
640*400 bzw. TT 1280*960) ist das Monochrome-Detect-Bit ge¬ 
löscht, sonst gesetzt. Wenn der FIFO-Puffer des Soundchips das 
letzte mal gefüllt wurde, wird dieses Bit Nr. 7 im GPIP in Moncro- 
me gesetzt und das Beschreiben der neuen Start/Endadresse kann 
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nun erfolgen. Man kann den MFP bei Änderung von 17 einen Inter¬ 
rupt auslösen lassen und so, wie im TIMER A Interrupt, die neue 
Frame Start/Endadresse eintragen. 


4.4. Mehrstimmiges Abspielen von Samples 

per DMA und PSG 

Wie schon in Programmen zum ersten Teil des Buches gezeigt, ist 
es auf jedem ATARI (ST-TT-Falcon sowieso) möglich, digitalisierte 
Sounds mehrstimmig abspielen zu lassen. An dieser Stelle möchte 
ich erklären, wie es möglich ist, dabei sowohl die Frequenz als 
auch die Lautstärke jeder einzelnen Stimme zu verändern. 


4.4.1 Das Mischen von Samples 

Geräusche lassen sich in digitaler Form fast genauso mischen wie 
in der Natur, durch Addition. Wenn man zwei Geräusche in der Na¬ 
tur mischt, z.B. wenn zwei Personen gleichzeitig sprechen, addie¬ 
ren sich Wellen und Täler. Im Computer übernimmt das Rechen¬ 
werk eines Prozessors, in der Regel die CPU - beim Falcon der 
DSP, der speziell für solche Aufgaben gebaut wurde und das ent¬ 
sprechend schneller kann. Wenn wir nun zwei ziemlich hoch aus¬ 
gesteuerte Werte miteinander addieren, überschreiten wir den Be¬ 
reich, den unser D/A Wandler abzuspielen vermag. Eine einfache 
Lösung ist, wenn man die Werte vor dem Abspielen auf den halben 
Maximal-Wert bringt, allerdings spielt man ja gelegentlich nur eine 
Stimme ab, dann wird die einzelne Stimme extrem leise. Aber auch 
dieses Problem läßt sich lösen, so kann man für eine nicht vorhan¬ 
dene Stimme z.B. einen fixen Wert dazu addieren, ideal ist dabei 
ein Wert, der beim PSG bei 128 (da dort die Samplewerte im For¬ 
mat unsigned Byte vorliegen), also der X - Achse, liegt. 

Im allgemeinen werden aber volle 8 Bit Samples genommen, die 
einzelnen Werte dieser Samples wenden in eine 16 Bit Register- 
Hälfte addiert und dann um ein Bit nach rechts verschoben (durch 
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zwei geteilt). Auf diesem Wege hat man zwei Samples miteinander 
addiert. Natürlich wird, wenn ein Sample länger als der andere ist, 
nachdem das kürzere Sample beendet ist, statt der vom ausge¬ 
spielten Sample stammenden Werte der Wert der X - Achse zum 
noch abzuspielenden Sample addiert. 

Einleuchtend ist, daß es nur sinnvoll ist, eine Anzahl von Stimmen 
zu addieren, die man durch einen Shift-Befehl auch teilen kann, al¬ 
so 2/4/8 ... Stimmen, da eine Division mit dem entsprechenden As¬ 
semblerbefehl fast das Zehnfache an Rechenzeit schluckt. 


4.4.2 Mehrstimmiges Abspielen mit unterschiedlicher Tonhöhe 

Da es selbst auf dem Falcon nicht so ohne weiteres möglich ist, die 
Abspielfrequenz der DMA - Soundkanäle variabel zu wählen, muß 
man das, was man abspielt, so modifizieren, daß es sich so anhört 
als könne man dies. 

Aber wie ? 

Nichts einfacher als das !? 

Beim DMA - Soundchip legt man sich einen Puffer an und strecke 
bzw. stauche das, was man hineinschreibt. 

Hier ein kleines Beispiel für 8 Bit Samples: 

in Dl steht der Faktor zum Strecken bzw. Stauchen 
in AI steht die Adresse des abzuspielenden Samples 

add.l D1,D2 
swap D2 

D2 enthält hier im unteren Wort den Offset 

move.b 0(A1,D2.w),D3 
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In D3 steht das in den Puffer zu übertragende bzw. vom PSG ab¬ 
zuspielende Byte. Es steht in D3, da diese Technik auch beim 
mehrstimmigen Abspielen verwendet werden kann, also noch ein 
weiteres Sample addiert werden könnte. 

swap D2 

Nun, wie funktioniert das genau ? 

Wenn z.B. ein sehr kleiner Wert in Dl steht, dann wird das nieder¬ 
wertige Wort gefüllt. Irgendwann gibt es dann einen Übertrag auf 
das höherwertige Wort. Durch das Tauschen des höherwertigen 
Wortes mit dem niederwertigen befindet sich im unteren Wort nur 
der Übertrag. Dieser wird dann zu Adressberechnung genommen 
und das Byte aus dem Sample geholt. Das funktioniert auch, wenn 
sich sehr große Werte in Dl befinden (!) die Frequenz läßt sich in 
einer Auflösung von etwa einem 65536stel einstellen. Das ist eine 
Art von 32-Bit-Festkommazahlen-Berechnung, wobei sich das 
Komma immer an der Stelle befindet, wo der Übertrag von einem 
zum anderen Wort stattfindet. 

Mit dieser Technik werden z.B. die unterschiedlichen Frequenzen 
der 4 Stimmen bei einigen MOD - Playern auf dem ATARI erzeugt. 


4.4.3 Lautstärkeregelung beim Abspielen von Samples 

Wenn man nun mehrere Samples zusammenmischt, hat man das 
Problem, das man möglicherweise zwar die Lautstärke des D/A 
Wandlers regeln kann, z.B. beim DMA - Soundchip von 
STE/TT/Falcon, aber nicht die Lautstärke jeder einzelnen Stimme. 

Eine Möglichkeit die Lautstärke zu regeln ist, sich so viele Tabellen 
zu erstellen wie man sich Lautstärkestufen wünscht. Wobei die Ta¬ 
bellen so gestaucht werden müssen, daß sie je nach Format (sig- 
ned oder unsigned) 
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8 Bit signed: 

-128 

0 X - Achse 
127 

8 Bit unsigned: 

0 

127 X-Achse 
255 

von der höchsten bzw. niedrigsten zum Nullpunkt hin gestaucht 
werden müssen!!! 

Eine andere Möglichkeit besteht darin, sich eine Tabelle zu schrei¬ 
ben, deren Länge je nach Abstufungen in den Lautstärken und Dy¬ 
namik gewählt werden muß. Diese Tabelle fällt nicht ganz so 
schnell ab wie eine 1:1 Tabelle (1 Wert in Tabelle = 1 Wert beim 
Sample Datum). Wenn man die Lautstärke verschieben will, ver¬ 
schiebt man den X - Achsenschnittpunkt in der Tabelle und addiert 
eine Konstante zu dem Ausgangswert, um den wieder in dem rich¬ 
tigen Verhältnis zur X Achse zu wissen . Ein Beispiel dazu befin¬ 
det sich in den Modeplayer Sources. 


4.5. Das Falcon DMA - Sound Subsystem 

Nun komme ich zu den Änderungen und erheblichen Erweiterun¬ 
gen, die ATARI dem DMA - Sound des Falcon hat angedeihen las¬ 
sen. 


4.5.1 Die Architektur des Falcon030 - Soundsubsystem 

Zur besseren Verständlichkeit sehe ich die DMA getrennt von den 
restlichen Geräten (Devices), weil sie die Verbindung zum Spie- 
cher und somit zu CPU den im Speicher abgelegten Klängen etc. 
darstellt. Sie kann aber wie jedes andere Gerät über die Verbin¬ 
dungsmatrix verschaltet werden. 
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Das Soundsubsystem besteht aus: 

DMA 

1) DMA Output Kanal, Speicher nach Device 

2) DMA Input Kanal, Device nach Speicher 

Diese zwei Kanäle können je bis zu 1 MB/s übertragen und der 
Prozesssor wird zyklisch unterbrochen, damit die Kanäle ihre 32 
Byte FIFOS (Pufferspeicher) füllen können. Diese beiden Kanäle 
arbeiten (relativ) unabhängig voneinander. Über eine Verbindungs¬ 
matrix, mit der es möglich ist, die Devices untereinander und mit 
den DMA Kanälen zu verbinden, ist es sogar möglich, DMA Input 
mit DMA Output zu verbinden um somit ähnlich wie beim AMIGA- 
Blitter Daten von Speicher nach Speicher zu kopieren, ohne daß 
die CPU auf das Ende des Vorhangs ,wie beim ATARI Blitter, war¬ 
ten muß. Bei hoher Busauslastung z.B. "True" Color Auflösung, 
kann es passieren, daß die DMA-Kanäle ihre FIFOS nicht mehr 
schnell genug füllen bzw. in den Speicher übertragen können, was 
den Verlust von Daten zur Folge hat. Es ist zwar möglich, zwi¬ 
schen DMA/Devices im Handshake (Gerät bestätigt Empfang der 
Daten und bekommt dann erst weitere gesendet) zu übertragen, es 
ist mir allerdings nicht gelungen, DMA Input nach DMA Output im 
Handshake Modus Daten zu schaufeln (wahrscheinlich nicht vor¬ 
gesehen). 

Device Teil 

1) External Input/Output, DSP Buchse, Externer serieller Ein-/ 
Ausgang 

2) DSP transmit/receive, Signalprozessor Ein/Ausgang 
siehe Kapitel B.5 

3) CODEC A/D - D/A Wandler, Kopfhörer/Mikrofon Anschluß 
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Der CODEC ist ein 16 Bit STEREO Analog/Digital und Digital/Ana¬ 
log Wandler, mit ihm sind sowohl Aufnahme wie auch Abspielfre¬ 
quenzen bis 50kHz möglich. Über den DMA Input Kanal könnte 
man allerdings 4 CODEC’s parallel mit Daten bei ca. 50kHz betrei¬ 
ben. Alle 4 STERO Sound - Kanäle können nur auf den CODEC 
abgespielt werden, wenn man diese vorher zusammen mischt, 
wenn man die DMA Kanäle auf den DSP richtet, könnte dieser das 
übernehmen und den Sound dann vierstimmig und möglicherweise 
bearbeitet (Filter, Echo etc.) auf den CODEC geben. 

Für den A/D Wandler ist der Mikrofon-Anschluß oder der PSG als 
Eingang zuschaltbar. Nur auf diese Weise ist der PSG in den F030 
integriert, d.h. bei niedriger Abspielfrequenz, die beim CODEC 
auch immer der Abtastfrequenz entspricht, wird auch der PSG 
Soundchip Sound entsprechend an Brillianz verlieren (kein großer 
Verlust !). Den PSG und A/D Wandler gleichzeitig zu Gehör zu 
bringen ist im F030 nicht möglich. 

16 Bit Addierer (wahrscheinlich im CODEC integriert) 

Mit ihm ist es möglich, das A/D Signal mit dem D/A Signal zu kop¬ 
peln, um somit eine Mithören des Eingangssignals (monitoring) zu 
ermöglichen. 

Verbindungs Matrix 

Ermöglicht es, eine Quelle z.B. A/D-Wandler mit mehreren Zielen 
z.B. DMA Kanal in den Speicher zu übertragen. 


4.5.2 Programmierung des FALCON - Soundsubsystems 

Im Gegensatz zum VIDEO - Subsystem des F030 hat ATARI bei 
den Aufrufen des Soundsubsystem wirklich ganze Arbeit geleistet, 
so daß man im Prinzip nicht versucht ist, auf die dazu vorhandene 
Hardwareregister, die von $ffff8900 bis etwa $ffff893A liegen, zu¬ 
zugreifen. 
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Nomenklatur: 

WORD = 16 Bit 

LONG = 32 Bit 

VOID = Dummy, d.h. keine Rückgabe 

* = Zeiger auf 

Rückgabe erfolgt in DO 

Beispiel: 

XBIOS 133 

VOID settracks(WORD playtracks,WORD rectracks) 
ist 

move.w #rectracks ,-(sp) 
move.w #playtracks,-(sp) 
move.w #133,-(sp) 
trap #14 

addq.l #6,sp 


XBIOS 128 

LONG locksnd() 

Sperrt das DMA - Soundsubsystem, so daß keine andere Applika¬ 
tion eine Änderung vornehmen kann. 

gibt bei geglücktem Aufruf Null zurück. 

sonst -128, wenn das DMA - Soundsubsystem schon gesperrt 
wurde. 
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XBIOS 129 

LONG unlocksnd() 

Gibt das DMA - Soundsubsystem wieder frei. 

gibt bei geglücktem Aufruf 0 zurück. 

sonst -129, wenn das Soundsubsystem nicht gesperrt war. 


XBIOS 130 

LONG soundcmd(WORD mode, WORD data) 

Setzen der Ausgangslautstärke, z.B. eingebauter Lautsprecher 

15 = volle Lautstärke, 240 = geringste Lautstärke 

mode: 0 LTATTEN linker Kanal in -1 .5db Schritten 
data: %XXXX XXXX INI XXXX 

Rückgabe: %XXXX XXXX INI XXXX 

mode: 1 RTATTEN rechter Kanal in 1 ,5db Schritten 
data: %XXXX XXXX rrrr XXXX 

Rückgebe: %XXXX XXXX rrrr XXXX 

Setzen der Eingangslautstärke, z.B. Mikrofon Eingang oder PSG 

240 = volle Lautstärke, 15 = geringste Lautstärke 

mode: 2 LTGAIN rechter Kanal in 1.5db Schritten 
data: %XXXX XXXX llll XXXX 

Rückgabe: %XXXX XXXX llll XXXX 

mode: 3 RTGAIN rechter Kanal in 1,5db Schitten 
data: %XXXX XXXX llll XXXX 

Rückgabe: %XXXX XXXX llll XXXX 
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Setzen der Quellen für den 16 Bit Addierer 

Wichtig ! Wenn man DMA u. PSG gleichzeitig spielen lassen möch¬ 
te, müssen wie im STE/TT beide Bits gesetzt sein. 

mode: 4 adderin 

data: BIT 7 6 5 4 3 2 1 0 

000000MA 

A = ADC , (Analog Digital Converter) Mikrofoneingang 

M = Matrix , 4*4 Quell - Ziel Matrix 

gibt ein Wort mit altem Status zurück 

Setzen der Quelle für den Analog Digital Wandler (ADC) 

mode: 5 adcinput 

data: BIT 7 6 5 4 3 2 1 0 

000000LR 

L: Linker Kanal 

R: Rechter Kanal 

wenn gesetzt PSG, sonst Mikrofon Eingang 

Es ist damit möglich, den linken oder rechten Kanal vom Mikrofon 
oder PSG auf den A/D Wandler zu schicken; dieser Eingang läßt 
sich dann über den 16 Bit-Addierer mit dem DMA Sound mischen 
und zum Lautsprecher/Kopfhörerausgang schicken. 

gibt ein Wort mit altem Status zurück 

Setzen dee STE/TT Vorteilung 

Die hier eingestellten Werte werden vom System nur genutzt, wenn 
bei ’devconnect’ der Wert von ’prescale’ auf Null gesetzt ist. 
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mode: 6 setprescale 

DATA: 0 - Nicht möglich d.h. kein Ton 

1 - Teiler 640 entspricht 12.5 kHz STE/TT 

2 - Teiler 320 entspricht 25.0 kHz STE/TT 

3 - Teiler 160 entspricht 50.0 kHz STE/TT 


XBIOS 131 

LONG setbuffer(WORD reg, LONG begaddr, LONG endaddr) 

Zum Setzen der Anfang/Endadresse eines Aufnahme/Abspielpuf¬ 
fers, auf den dann von der Sound DMA zugegriffen werden kann. 

reg = 0 abspielen, 1 aufnehmen 
begaddr = Startadresse des Puffers 
endaddr = Endadresse des Puffers 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 


XBIOS 132 

LONG setmode(WORD mode) 

Voreinstellung der Sound Kanäle, gilt für Aufnahme und Wieder¬ 
gabekanäle gleichermaßen. 

mode, 0 = 8 Bit STEREO (STE/TT compatibel) 

1 =16 Bit STEREO 

2 = 8 Bit MONO (STE/TT compatibel) 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 
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XBIOS133 

LONG settracks(WORD playtracks, WORD rectracks) 

Setzt die Menge der Kanäle für Aufnahme und Wiedergabe. 

playtracks , 0 bis 3 
rectracks , 0 bis 3 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 


XBIOS 134 

LONG setmontracks(WORD montrack) 

Mit diesem Aufruf kann man einstellen, welcher der "vier" Sound¬ 
kanäle über den CODEC ausgegeben werden, da nur ein D/A 
Wandler vorhanden ist, kann das immer nur ein Kanal sein. 

montrack, 0 bis 3 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 


XBIOS 135 

LONG setinterupt(WORD srcjnter, WORD cause) 

Das ist wichtig für die STE/TT-DMA-Sound-Kompatibilität, denn im 
Gegensatz zu deren DMA - Sound, bei dem am Ende des Puffers 
sowohl ein Timer A als auch ein MFP 17 Interrupt ausgelöst werden 
kann, läßt sich beim F030 extra einstellen, welcher Interrupt aus¬ 
gelöst werden soll, wenn das Ende des Wiedergabe-Puffers 
und/oder das Ende des Aufnahme-Puffers erreicht ist. 
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srcjnter , 0 = TIMER A, 1 = MFP 17 

cause , 0 = kein Interrupt, 1 = Wiedergabe, 2 = Aufnahme 
3 = Aufnahme und Wiedergabe 

Um STE/TT-Kompatibilität zu erreichen, muß TIMER A und MFP 
17 auf Interrupt am Ende des Wiedergabepuffers eingestellt werden. 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 


XBIOS 136 

LONG buffoper(WORD mode) 

Funktioniert im Prinzip wie beim STE/TT DMA - Sound 

mode, BIT 7 6 5 4 3 2 1 0 

0 0 0 0 RR RE PR PE 

Bit gesetzt gleich an 

PE Wiedergabe 

PR dauerndes Wiederholen des Wiedergabepuffers 
RE Aufnahme 

RR dauerndes Wiederholen des Aufnahmepuffers 

Wenn mode = -1, dann gibt die Funktion den Status der Bits zu¬ 
rück. Wenn die 32 Byte FIFO das Ende des Puffers erreichen, 
schalten die entsprechenden Bits PE und/oder RE kurzzeitig auf 0, 
selbst wenn das RR und/oder PR Bit (dauerndes Abspielen oder 
Aufnehmen von einem Puffer) gesetzt ist. 
oder gibt 0 zurück, wenn kein Fehler aufgetreten ist. 
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XBIOS 137 

LONG dsptristate(WORD dspxmit, WORD dsprec) 

Man kann mit diesem Aufruf den DSP von der Verbindungs-Matrix 
trennen. Wobei man das Senden als auch das Empfangen des DSP 
in/von der Matrix separat an/abschalten kann. 

dspxmit, DSP sendet in Matrix: 0 = abkoppeln, 1 = möglich 

dsprex, DSP empfängt von der Matrix: 0 = abkoppeln, 1 = möglich 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 


XBIOS 138 

LONG gpio(WORD mode, WORD data) 

Dieser Aufruf dient zur Ansteuerung der GP Pins der DSP Buchse. 

mode, 0 = setze Ein/Ausgabe Richtung 

1 = Lesen 

2 = Schreiben 

data: %rrrrrrrr rrrrrnnn r = reserviert, n = benutzt 

wenn mode =0, dann setzt data die Ein/Ausgabe Richtung der Pins 
wenn mode =2, der Inhalt von data bestimmt den Pegel an den GP 
Pins der DSP Buchse 

gibt zurück: 

für mode = 1 (lesen), die anliegenden Pegel an den GP Pins DSP 
Buchse als Bitmuster 

sonst 0 
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XBIOS 139 

LONG devconnect( WORD src, WORD dst, WORD srcclk, 

WORD prescale, WORD protocol) 

Dieser Aufruf, macht ’ne ganze Menge ! 

Er verbindet eine Quelle mit dem gewünschten Ziel in der Verbin¬ 
dungsmatrix. Wobei die Quelle immer nur ein Device und Ziel meh¬ 
rere Devices sein können. Außerdem kann man mit dieser XBIOS 
Funktion den Takt und den Vorteiler für das Sound - Subsystem, 
sowie das Protokoll zwischen den einzelnen Devices wählen. 

src, (source) setze Quelle für die Verbindungsmatrix 

0 = DMA Wiedergabe 

1 = DSPXMIT (DSP Senden) 

2 = EXTINP (Externer Eingang) 

3 = ADC (Mikrofon Buchse oder PSG) 

dst, (destination) setzt Ziele in der Verbindungsmatrix 

Bit 0, DMA Aufnahme 

1, DSPRECV (DSP Empfangen) 

2, EXTOUT (Externer Ausgang) 

3, DAC (Kopfhörerbuchse oder Lautsprecher) 


srcclk, was als Takt für CODEC und DMA benutzt wird 

0 = 25.175 MHz intern (STE/TT kompatibel) 

1 = extern (von der DSP Buchse) 

2 = 32 MHz intern 
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prescale, Vorteiler für den anliegenden Takt 

Darf Werte von 0 bis 12 annehmen, Werte größer als 12 schalten 
das System still, Werte von 1 bis 12 werden als Vorteiler für den 
Takt/256 verwendet. Wenn der Vorteiler null ist wird der STE/TT 
kompatibele Vorteiler benutzt, siehe soundcmd (XBIOS 130) 

protocol, 

Schaltet das Handshaking zwischen den Devices an und aus 

0 = Handshaking an 
1 = Handshaking aus 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 


XBIOS 140 

LONG sndstatus(WORD reset) 

Mit diesem Aufruf erhält man die momentane Verfassung des 
CODEC. 

Die Rückgabe erfolgt im niederwertigen Nibble. Auch wird zurück¬ 
geliefert, ob der rechte oder linke Kanal während der A/D Wandlung 
und des Filterns übersteuert wurden. 

reset: 

wenn 1 dann wird das komplette Sound - Subsytem initialisiert. 

DSP von Verbindungsmatrix getrennt (tristatet) 

Lautstärke Aufnahme u. Wiedergabe auf Null gestellt 
Matrix Verbindungen werden zurückgesetzt 
ADDERIN - der Addierer wird ausgeschaltet 
mode ist 8 Bit Stereo 
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Aufnahme/Wiedergabe Kanäle werden auf Null gesetzt 
Abhörkanal ist Null 

keine Interrupts am Pufferende (TIMER A, MFP 17) 
keine Puffer gesetzt 

gibt den Status des CODEC zurück 

Bits 0 bis 3 %SSS 

0 = kein Fehler aufgetreten 

1 = ungültiges Kontrollfeld 

2=ungültiges Syncformat (CODEC schaltet still) 

3=Takt wird vom CODEC nicht unterstützt (CODEC schaltet still) 

Bit 4 & 5 %LR 

R = rechter Kanal übersteuert 
R = linker Kanal übersteuert 

XBIOS 141 

LONG buffptr(LONG ‘pointer) 

Diese Funktion gibt die "momentane" Position der Aufnahme, 
Wiedergabe DMA in den Puffern zurück. 

’pointer, Zeiger auf vier Langworte in denen nach dem Aufruf fol¬ 
gendes steht 

1. LONG, DMA Position im Wiedergabe-Puffer 

2. LONG, DMA Position im Aufnahme-Puffer 

3. LONG, reserviert 

4. LONG, reserviert 

gibt 0 zurück, wenn kein Fehler aufgetreten ist. 
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Hier die ’prescale’ Tabelle für ’devconnect’! 


Wert 

Frequenz 


0 

STE/TT kompatibler Vorteiler 

1 

49170Hz 


2 

33880Hz 


3 

24585Hz 


4 

20770Hz 


5 

16490 Hz 


6 

14285 Hz 

CODEC nicht geeignet für diese Frequenz 

7 

12292 Hz 


8 

11110 Hz 

CODEC nicht geeignet für diese Frequenz 

9 

9834 Hz 


10 

9090 Hz 

CODEC nicht geeignet für diese Frequenz 

11 

8195 Hz 


12 

7690 Hz 


13 

7140 Hz 


14 

6660 Hz 


15 

6250 Hz 


Leider 

kann es zu Problemen kommen, wenn XBIOS Aufrufe aus 


einem Interrupt erfolgen, da das XBIOS nur beschränkt reintrant 
ist, das bereitet größere Probleme beim DMA - Sound Subsystem, 
da ja dessen Hardwareregister nicht dokumentiert sind, man aber 
nur über XBIOS Aufrufe die DMA Puffer setzen kann. Wenn also 
am Ende des Puffers ein TIMER A oder ein 17 Interrupt erfolgt, 
kann man nicht unbedingt in dieser Interruptroutine einen XBIOS- 
Call absetzen, man muß zuvor einige Vorkehrungen treffen. 

Zu diesem Zweck gibt es eine Systemvariable, ’savptr’ an der 
Adresse $4a2, die den Zeiger auf die Adresse des Speicherbe¬ 
reichs enthält, in dem XBIOS und BIOS Registerinhalte, Rück¬ 
sprungadressen etc. gerettet werden. Beim Eintritt in den Interrupt 
sollte man, wenn man eine XBIOS/BIOS Funktion aufrufen will, den 
in ’savptr' enthaltene Zeiger um 46 Bytes heruntersetzen und vor 
der Beendigung der Routine wieder zurücksetzen. So darf sich im¬ 
mer nur eine Interruptroutine verhalten und es ist nur Platz für ca. 
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drei Rekursionen der Interruptroutine d.h. der Zeiger darf nicht 
mehr als 138 Bytes nach unten geschoben werden, für mehr ist 
eben kein Platz. 


4.6 Das Microwire Interface (nur STE/TT) 

Da hat Atari einen kleinen Equalizer springen lassen ! 

Im Prinzip ist das Microwire Interface nur der Chip, der den kleinen 
Equalizer (LMC1992) anspricht und zwar in einer Geschwindigkeit 
von 16x10' 6 s. In ST-TT ist dieses Interface nur dazu da, um den 
LMC1992, anzusprechen. Es wäre allerdings möglich, auch andere 
Geräte über dieses Interface anzusprechen, warten wir also auf die 
zukünftigen Erweiterungen ATARI’s. In den F030 Entwicklergerä¬ 
ten war das Microwire Interface noch vorhanden, bei den Serienge¬ 
räten fiel das Interface dem Rotstift zum Opfer. Allerdings läßt sich 
die Klangregelung des LMC1992 auch gut mit Falcon’s DSP 56001 
(Signal Prozessor) nachahmen, aber dazu mehr in Kapitel 7, das 
sich mit dem DSP beschäftigt. 
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4.6.1 Die Hardware - Register des Microwire Interface 

Adress+Data Bits 

$ff 8922 W %nnnn nnnn nnnn nnnn RW MWDATA 
Adress+Data Bits Bedeutung: 

Bits: 

10-11 Adresse des Gerätes (Device 10 = LMC1992) 
restlichen Bits sind Daten, die der LMC so interpretiert: 

Bits: 

7-9 MODUS restlichen Bits: 

000 Mischung einstellen 

XXXX nn 
I I 

00 -12 dB 

01 mische PSG zum Ausgang 

I 0 mische PSG nicht zum Ausgang 

II reserviert 

001 Baß (50 Hz) 

010 Höhen (15 kHz) 

XX nnnn 
I III 

0 000 -12 dB 

0 110 Mitte 

1 1 00 +12 dB 
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100 rechte Lautstärke 

101 linke Lautstärke 


X nn 

1 1 

nnn 

i i i 

1 1 

00 

i i i 

000-40 dB 

01 

01 0-20 dB 

1 0 

1 XX 0 dB 

Gesamt-Lautstärke 

nnn 

i i i 

nnn 

i i i 

i i i 

000 

i i i 

000-80 dB 

01 0 

1 00-40 dB 

1 01 

XXX 0 dB 


Mask-Register 

$ff 8924 W %nnnn nnnn nnnn nnnn RW MWMASK 

Wenn das Data Register beschrieben wird, wird das Mask Register 
geshiftet; es dauert eine gewisse Zeit, bis das Register neu be¬ 
schrieben werden kann, denn der Inhalt des Data - Registers wird 
hinausgeschoben und damit quasi in das angegebene Gerät (z.B. 
%10 LMC1992) übertragen. Gleichzeitig wird das Mask-Register 
gerollt; wenn das Mask Register seinen alten Zustand hat, sind alle 
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Bits des Data Registers übertragen worden, allerdings muß dafür 
das Mask - Register eine Bitkombination enthalten; die nur wenn 
sie ganz "durchgerollt" wurde; wieder die ursprüngliche Zahl ergibt 
z.B. $07FF. 


4.6.2 Einfaches Nutzen des LMC1992 

Voraussetzung: 

Letzte Übertragung geschah genauso (also alle Bits schon durch¬ 
geschoben). 


MWMASK 

equ $ffff8924 


MWDATA 

equ $ffff8922 


move.w 

#$07FF,MWMASK. w 

; Nur beim ersten Zugriff 

move.w 

#%10000000010,MWDATA. w 

; PSG wird nicht zum 
; Ausgang dazu gemischt 

cmp.w 

#$07ff,MWMASK. W 



Erklärung: 

Beim allerersten Zugriff schreibt man #$07ff in das Mask -Register, 
dann kann man das gewünschte Datum in das Datenregister 
schreiben z.B. %10 000 000 010 

I I I 

DEVICE SET-MIX kein PSG zum Ausgang 

bei jedem weiteren Zugriff ist es im Prinzip nicht nötig, das Mas¬ 
kenregister neu zu beschreiben, denn es behält ja seinen Inhalt. 
Jedoch kann es durchaus passieren, daß jemand einen anderen 
Wert in das Maskenregister hinein schreibt, z.B. ein parallel laufen¬ 
des Programm (unter MINT oder MULTI TOS). 
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4.7. Das Amiga Sound - Modul (MOD) Format 

Offset 

$00 - $13 Name des Moduls 
$14 - $3b5 31 je 30 Byte große Einträge für maximal 

31 Samples 

Aufbau der Einträge: 

$00 - $15 Name des Samples 
$16 Länge des Samples/2 
$18 Lautstärke des Samples ($00-$40) 
$20 Loop Beginn von Sampleanfang 
Offset/2 

$22 Looplänge/2 

$3b6 Anzahl der Patterns 
$3b7 Frei 

$3b8 Patternliste, gibt an, in welcher Reihenfolge 
die Patterns abgespielt werden. 

$438 Zeichen des Soundtrackers, mit dem das ’MOD’ 
erstellt wurde 

$439 Noten 1024 Byte (4 Noten * 64 pro Pattern) 
in der Reihenfolge: 

1. Note Stimme 1 
1. Note Stimme 2 
1. Note Stimme 3 
1. Note Stimme 4 

usw. 

anschließend folgen die Samples 
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Format einer Note: 

N = Nibble 
N NNN N N NN 

I I I I I_Intensität des Effekts 

I I I I 

I I I I_Effekt 

I I I 

I I I_ Nr. des Samples 

I I Low Nibble 

I I 

I I_ Tonhöhe (Periode) 

I (Amiga Hardware spezifisch) 

I 

I_ Nr. des Samples 

High Nibble 


Format der Tonhöhe: 


Perioden - Werte 


1. Oktave 


2. Oktave 3. Oktave 


c 

$3 58 

$ 1 AC 

$ 0 D6 

c# 

$3 28 

$1 94 

$ 0 CA 

D 

$2 FA 

$ 1 7D 

$ 0 BE 

D# 

$2 DO 

$ 1 68 

$ 0 B4 

E 

$ 2 A6 

$ 1 53 

$ 0 AA 

F 

$2 80 

$ 1 40 

$ 0 AO 

F# 

$ 2 5C 

$ 1 2E 

$0 97 

G 

$ 2 3A 

$ 1 ID 

$ 0 8F 

G# 

$2 1A 

$1 0D 

$0 87 

A 

$1 FC 

$ 0 FE 

$ 0 7F 

A# 

$ 1 E0 

$ 0 F0 

$0 78 

H 

$ 1 C5 

$ 0 E2 

$0 71 
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Effekte: 

(entnommen aus der Anleitung zu NoiseTracker 1.1) 


0 - arpeggio 

1 - portamento up 

2 - portamento down 

3 - Tone-portamento 

4 - Vibrato 


A - Slide volume 
B - Position jump 
C - Set volume 
D - Pattem break 
E - Set filter 
F - Set speed 


$0 Arpeggio - $0 + zweiter & dritter Halbton über der Note 
Erzeugt einen Akkord mit nur einer Stimme 

C-3 00037 erzeugt darüber liegenden Akkord 
C-3 00047 erzeugt darunter liegenden Akkord 

$1 Portamento up - $1 + Geschwindigkeit 
Erhöht langsam die Tonhöhe 
C-3 00103 1 ist der Befehl, 3 die Geschwindigkeit. 

$2 Portamento down - $2 + Geschwindigkeit 
Läßt die Tonhöhe fallen 

C-3 00203 2 ist der Befehl, 3 ist die Geschwindigkeit. 

$3 Tone-portamento - Ziel Note + $3 + Geschwindigkeit 
Langsames Verändern von der Tonhöhe der letzten Note 
zur kommenden. 

C-3 00305 C-3 Note, zu der erhöht wird, 3 der Befehl, 

5 die Geschwindigkeit. 

$4 Vibrato - $4 + Vibratogeschwindigkeit + Vibratospanne 

C-3 00481 4 der Befehl, 8 die Vibratorgeschwindigkeit, 

1 Vibratodynamik 

Um das Vibrato fortzusetzen, muß man nur die 4 in der näch¬ 
sten Note setzen. 
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$A Volume-slide - $A + Geschwindigkeit nach oben bzw. unten 

C-3 00A05 5 Geschwindigkeit nach oben 
C-3 00A40 4 Geschwindigkeit nach unten 

$B Position-jump - $B + Position an der Fortgesetzt wird 

C-3 00B01 1 ist die Position an der das Lied fortgesetzt 

wird. 

Das laufende Pattem wird unterbrochen ! 

$C Set volume - $C + neue Lautstärke 
Setzt die Lautstärke bis $40 möglich 

C-3 00C10 C ist der Befehl, 10 die Lautstärke. 

$D Pattern-break - $D + nothing 

Fährt fort mit dem nächsten Pattern 

C-3 00D00 D als Befehl, Rest egal 
$E Set filter - $E + Filter an/aus 

Man kann mit diesem Befehl auf einigen Amiga 500/2000er den 
Filter ein/ausschalten (auf dem STE/TT könnte man das mit 
dem Microwireinterface simulieren, auf dem Falcon sicherlich 
mit dem DSP 56001) 

C-3 00E01 Filter aus und LED aus 
C-3 00E00 Filter an und LED an 

$F Set speed - $F + Geschwindigkeit 

Ändert die Geschwindigkeit, in der der Song abgespielt 
wird, Geschwindigkeiten $01 - $1f sind erlaubt 
C-3 00F07 stellt die Geschwindigkeit auf 7 ein 
d.h. alle 7*20ms wird eine neue Note gespielt. 

Die Wirkungen der Effekte werden alle 20ms geändert! 
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B.5. Das Ansteuern von Klangerzeugern per 
MIDI Schnittstelle 

Wer schon mal eines der Sierra Adventures mit über MIDI ange¬ 
schlossenen MT-32 gespielt hat, weiß, daß die Musik, die man da 
hören kann, schon fast dem Soundtrack eines Films gleich kommt. 
Insofern ist diese MIDI - Schnittstelle für Spieleprogrammierer 
schon eine sehr interessante Sache. Leider machen sich nur weni¬ 
ge Firmen die Mühe, dieses Feature in ihren Programmen zu nut¬ 
zen. Obwohl das Implemetieren der MIDI Abspielroutinen in vielen 
Fällen nur ein geringfügiger Mehraufwand bedeuten würde. Auch 
haben die wenigsten exzessiven Spieler, also im Prinzip der Markt 
der Spielehersteller einen MIDI-fähigen Klangerzeuger. Also war¬ 
um, denkt sich der Programmierer, soll man sich die Mühe machen 
etwas anzusteuern, was eh keiner besitzt. Der Konsument sieht in 
diesem Fall natürlich nicht ein, wieso er sich einen Expander (Syn¬ 
thesizer ohne Tasten) kaufen soll, wenn es kein Spiel gibt, das so 
ein Teil unterstützt (eine verfahrene Sache). 

Was ich damit sagen will, man sollte sich gelegentlich überlegen, in 
Demos und Spielen mit viel Musik MIDI zu unterstützen. 


5.1 Was ist MIDI ? 

MIDI (Musical Instrument Digital Interface also eine digitale Mu- 
sik-lnstrumenten-Schnittstelle) ist eine genormte Schnittstelle zwi¬ 
schen Musik-Instrumenten, Sequenzern, Computer, Mischpulten 
und vielem mehr. Irgendwann zu Beginn der 80er Jahre haben sich 
namhafte Hersteller von Synthesizern und ähnlichem hervoragen- 
dem Gerät zusammengesetzt um eine Schnittstelle zwischen ihren 
Erzeugnissen zu entwerfen. Diese Schnittstelle hat eine maximale 
Übertragungsrate von 31 KBit, das sind fast 4 Kbaud (Kilobyte pro 
Sekunde). Aber auch das ist bei großen Geräteparks manchmal zu 
wenig, und es kommt zu den sogenannten "MIDI delays“ , d.h. das 
erste Gerät in der MIDI-Schlange spielt die Note merklich früher 
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als das letzte. Die MIDI-Daten werden alle byteweise übertragen (8 
Bit, getrennt durch Start- und Stopp-Bit), auch sollten die MIDI - 
Verbindungskabel nicht länger als 15 Meter sein. 

So, das war das Formelle, jetzt kommen wir zur... 

5.2. Allgemeine MIDI Nomenklatur 

5.2.1 Was ist ein MIDI Kanal ? 

Zu jedem Befehl, der über MIDI gesendet wird, wird noch der Ml- 
Dl-Kanal dazugesendet um sicherzustellen, daß er auch vom rich¬ 
tigen Gerät oder richtigem Teil eines Gerätes empfangen wird. So 
ist es möglich, bis zu 16 verschiedene Geräte über einen MIDI 
Ausgang zu steuern. Natürlich muß man zuvor auch die entspre¬ 
chenden Kanäle an den Geräten eingestellt haben. Den MIDI Kanal 
kann man sich wie die Telefonnummer eines Gerätes vorstellen, 
nur das Gerät, das die richtige Nummer hat nimmt auch die ent¬ 
sprechenden Daten an. Wenn zwei Geräte dieselbe Nummer ha¬ 
ben, spielen sie auch beide dieselben Noten. 


5.2.2 Unterschiedliche MIDI Modes 

OMNI Empfang auf allen MIDI Kanälen gleichzeitig 
POLY mehrere Stimmen gleichzeitig 
MONO nur eine Stimme 

OMNI ON, POLY 

Das Gerät empfängt auf allen MIDI Kanälen und spielt die empfan¬ 
genen Noten alle ab. Ältere Geräte, wie die ersten Poly 800 (ließen 
sich mit neuem Eprom Umrüsten) besitzen diesen MIDI Mode, in 
einigen Geräten läßt er sich einstellen. In einem System mit meh¬ 
reren Geräten kann man ein Gerät mit dieser Einstellung nicht be¬ 
nutzen. 
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OMNI ON, MONO 

"Noch schlimmer", da soll eine Stimme alles spielen ??? 

OMNI OFF, POLY (MIDI MULTI MODE) 

Wenn zusätzlich noch eine dynamische Stimmenzuordnung dazu 
kommt ist das ideal ! Man kann damit aus nur einem Gerät mehrere 
unterschiedliche Sounds rausholen und durch unterschiedlichen 
MIDI - Kanäle steuern lassen. 

OMNI OFF, MONO 

Dieser Modi "verheizt" MIDI Kanäle, denn das Gerät empfängt auf 
jeder Stimme nur von einem bestimmten MIDI Kanal. 


5.2 Das MIDI Übertragungs Format 

Generell bedeutet ein gesetztes 8. Bit, daß es sich um einen Befehl 
handelt ! Die Daten, die nach einem solchen Befehl kommen dürfen 
das 8. Bit nicht verwenden, können also nur in einem Bereich zwi¬ 
schen 0-127 liegen. 
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5.3.1 Spielen einer Note 

Was hier kommt, sendet ein Keyboard beim Herunterdrücken einer 
Taste. 

z.B. NOTE an 

1. Byte, Status Note an (Bit 4-8), MIDI Kanal (Bit 1-4) 

%10010000 ($90) + MIDI Kanal %0000 ($0) bis %1111 ($F) 

2. Byte, Nummer der Note (7 Bit) 

wobei $0 der tiefsten und $7F der höchsten Note entspricht 

Beispiel einer Oktave: 

Kontra C 36 F# 42 

C# 37 G 43 

D 38 G# 44 

D# 39 A 45 

E 40 A# 46 

F 41 H 47 

u.s.w. 

3. Byte, Velocity (Anschlagdynamik - 7 Bit) 

wobei $0 der tiefsten und $7f der höchsten Note entspricht 

Wenn die eingeschaltete Note wieder ausgeschaltet werden soll, 
wird nochmals die gleiche Befehlsfolge geschickt. Das bedeutet, 
daß der Ton so lange eingeschaltet bleibt (gespielt wird) bis wieder 
ein Signal auf gleiche Tonhöhe geschickt wird. 

Die meisten Keyboards senden beim Ausschalten der Note einen 
Velocity Wert von Null, es sind aber auch andere Werte möglich. 
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5.3.2. Pitch Bend Signale 

Der Pitch Bend ist meist ein schwarzes Rad an dem Keyboard ei¬ 
nes Synthesizers oder Samplers, beim Betätigen dieses Rades, 
wird die Note der gerade am Keyboard ("Klaviatur") gedrückten 
Taste je nach Einstellung etwas nach oben oder nach unten trans¬ 
poniert. Je nach Fähigkeiten und Einstellung des Tonerzeugers 
wird die Note um eine halbe Note (Maximaleinstelllung des Pitch 
Benders), eine Oktave oder möglicherweise noch mehr transpo¬ 
niert. 

Die folgenden drei Bytes sendet ein Keyboard beim benutzen des 
Pitch Bend: 

1. Byte, Pitch Bend 

% 11100000 ($E0) + MIDI Kanal ($0 bis $F) 

2. Byte, niederwertige 7 Bit Pitch Bend Daten 
meist unbenutzt 

3. Byte, höherwertige 7 Bit Pitch Bend Daten 

$7F -- höchste Frequenz 
I 

$40 -- Mittelstellung 
I 

$0 - niedrigste Frequenz 

7 Bit bedeutet, das eine Zahl > $7F (127) einen Übertrag erzeugt, 
der auf das nächste Byte (dem höherwertigen), in diesem Fall ins 
dritte Byte übertragen wird. Das wird uns bei MIDI-Übertragungen 
noch öfters begegnen, da das achte Bit ja für die Befehle reserviert 
ist, d.h. Datenbytes können nicht größer als 7 Bit werden. 
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5.3.3. Programm Change 

Wechseln der Klänge auf den Geräten 

1. Byte, Umschalten (Befehlsbyte + MIDI - Kanal) 

% 11000000 (SCO) + MIDI Kanal ($0 bis $F) 

2. Byte, 7 Bit Klangnummer 

$0 bis $7f 

5.3.4. Aftertouch 

Diese Funktion bietet eine zusätzliche Kontrolle des Tons beim 
Spielen eines Keyboards. Das heißt, nach dem Herunterdrücken 
einer Taste kann man zusätzlich durch mehr oder weniger heftiges 
Herunterdrücken oder Nachlassen dieser Taste (meist) ein Vibrato 
erzeugen. Nun, es gibt hier zwei Arten dieser Funktion: 

a) Den monophonen Aftertouch, der auf das ganze Instrument und 
nicht nur auf die mit Druck versehene Taste wirkt: 

Format: 

1. Byte, monophoner Aftertouch 
%11010000 ($D0) + MIDI Kanal ($0 bis $F) 

2. Byte, Größe der Veränderung 
$0 keine bis $7F volle Wirkung 
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b) Den polyphonen Aftertouch, bei dem jede Stimme einer ge¬ 
drückten Taste durch entsprechenden Druck mit einem mehr 
oder weniger großen Wirkung eines Effekts (meist Vibrato) ver¬ 
sehen werden kann. 

1. Byte, polyphoner Aftertouch 

%10100000 ($A0) + MIDI Kanal ($0 bis $F) 

2. Byte, Note, auf die es wirkt 

$0 bis $7F 

3. Byte, Intensität 

$0 keine bis $7F volle Wirkung 


5.3.5 Control Changes 

Ich kann hier nicht alle möglichen Control Change Befehle auffüh¬ 
ren, da viele für den Spieleprogrammierer nicht so interessant sind 
und die Technik sich natürlich weiterentwickelt, d.h. viele Werte, 
die ich als unbenutzt kenne, sind möglicherweise von neueren Ge¬ 
räten schon belegt. 

Bei den folgenden Parametern ist das 1. Byte immer 
1. Byte, Controll Change + Midi Kanal 
%10110000 ($80) + MIDI Kanal ($0 bis $F) 

Übersicht: 

$0 - $1F Regler , $20 - $3F reserviert , 40 - 5F Schalter 

$60 - $79 reserviert , $7A - $7F Channel Mode Befehle 
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5.3.5.1 Modulations Rad 

Die Modulation kann bei vielen Samplern u. Synthesizern sowohl 
auf Tonhöhe als auch auf Filterstellung wirken, bei einigen Geräten 
sogar auf das Mischungsverhältnis von Oszillatoren, Resonanz 
u.v.m. 

Meist wird mit diesem Rad ein Oszillator gesteuert, der im Nieder¬ 
frequenzbereich die Tonhöhe des Orginaltons ständig um seinen 
Originalwert von oben nach unten variiert. 

2. Byte, $1 => Modulations Rad 

3. Byte, höherwertige 7 Bit 


$7F - 
1 

Volle Modulation 

1 

$40 - 
| 

Mittelstellung 

$0 - 

keine Modulation 


5.3.5.2. Breath Controller 

Der Anschluß für ein solches Gerät ist meist bei Yamaha Synthesi¬ 
zern zu finden, es ist ein Mundstück, mit dem man je nach Einstel¬ 
lung der Klangparameter, Tonhöhe und/oder Lautstärke mittels Hin¬ 
einblasen beeinflussen kann. 

2. Byte, $2 => Breath Controller 

3. Byte, Intensität 0 (keine) bis $7F (voll) 
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5.3.5.3. Fuß Pedal 

Eine Art Gas - Pedal für Synthesizer, je nach Gerät und Einstellun¬ 
gen kann man damit natürlich auch verschiedene Effekte erzeugen, 
wird jedoch meist zur Lautstärken-Regelung per Fuß genutzt. 

2. Byte, $4 => Foot Pedal Controller 

3 Byte, Intensität 0 (keine) bis $7F (voll) 


5.3.5.4. Portamento Time 

Wenn Portamento am empfangenden Gerät eingeschaltet ist, tritt 
beim Wechsel der Noten eine fließende Tonhöhenänderung auf. Mit 
der Portamento Time gibt man die Geschwindigkeit der Änderung 
an. 

2. Byte, $5 => Portamento Time 

3. Byte, Intensität $0 (keine) bis $7F (voll) 


5.3.5.5. Data Entry 

Regler am Synthesizer zur Dateneingabe, kann unterschiedlich be¬ 
legt sein ! 

2. Byte, $6 => Data Entry 

3. Byte, $0 bis $7F (je nach Funktion) 
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5.3.5.6. Gesamt Lautstärke 

Lautstärke des gesamten Synthesizers 

2. Byte, $7 => Main Volume 

3. Byte, 0 (keine) bis $7F (volle Lautstärke) 

5.3.5.6 Ein/Ausschalter 

2. Byte, 

$40 Hold/Sustain Pedal $41 Portamento 

$42 Sustenuto Pedal $43 Soft Pedal 

3. Byte, 0 = AUS - $7F =AN 

5.3.5.7. +/- Tasten zum Ändern der Daten 

Stufenweises Einstellen des DATA ENTRY ! 

2. Byte, $60 => +1 / $61 => -1 

5.3.5.7 Channel Mode Befehle 

Spezielle System-Einstellungen am Gerät: 

2. Byte, $7A Local Control, 3. Byte, 0 = AUS - $7F = AN 

"entkoppelt" Keyboard von Tonerzeuger, wenn Sie,sich im gleichen 
Gerät befinden. 

2. Byte, $7B All Notes Off 3. Byte, immer 0 
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Schaltet alle Noten aus, damit kann man Fehler bei der MIDI Über¬ 
tragung (sogenannte MIDI-Hänger), z.B. wenn ein NOTE ON Si¬ 
gnal aber kein NOTE OFF Signal gesendet wurde, ausbügeln. 

2. Byte, $7C OMNI MODE OFF 3. Byte, immer 0 

siehe 5.2.2. 

2. Byte $7D OMNI MODE ON 3. Byte, immer 0 
siehe 5.2.2. 

2. Byte $7E MONO ON/POLY OFF 3. Byte, $0 bis $7F 
Anzahl der MIDI Kanäle 

siehe 5.2.2. 

2. Byte $7F POLY ON/MONO OFF 3. Byte, immer 0 
siehe 5.2.2. 

5.3.6. Unter anderem gibt es noch die Common Commands 

Von diesen Befehlen werden alle Geräte beeinflußt 
1. Byte, %11110001 ($F1), % 11110100 ($F4), %11110101 ($F5) 
nicht definiert 

1. Byte, $F2 Song Position 

2. Byte, niederwertige 7 Bit der Posistion im Song eine Einheit = 6 
Midi Clockimpuls und 24 Impulse ergibt 1/4 Note 

3. Byte, höherwertigen 7 Bit der Position im Song 
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1. Byte, $F3 Song select 

2. Byte, 7 Bit enthalten die Song Nummer 

1. Byte, $F6 Tune request 
1. Byte, $FF System Reset 

5.3.7 Die Real Time Information 

Signale, die in Echtzeit zu Syncronisation von Instrumenten, z.B. 
Rythmußgeräte, Bandmaschienen benötigt werden. 

Immer nur ein Byte ! 

$F8 Timing Clock (24 Impulse = 1/4 Note) 

$F9 Nicht definiert 

$FA Start setzt den Zeiger für die Song-Position an den Anfang 

$FB Continue 

$FC STOP 

$FD Nicht definiert 

$FE Active sensing, eine Art Pausezeichen, wird den Geräten alle 
300 ms gesendet, um sie bereit zu halten. 


5.3.8. System Exclusive Daten 

Die System Exclusive Daten sind von Synthesizer zu Synthesizer 
unterschiedlich, es gibt sie für alle möglichen und "unmöglichen" 
MIDI Geräte, sofern sie programmierbar sind. Leider gibt es nur 
sehr wenige einheitliche Formate bei den System Exclusive Daten, 
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z.B. der MIDI Sample Dump Standard. In den anderen Bereichen 
kocht jeder Hersteller eines programmierbaren Geräts meist sein 
eigenes Süppchen, was es für den Spieleprogrammierer unmöglich 
macht, Sounds für seine Programme mit zu übertragen, außer er 
ist sich sicher, daß genau das Gerät angeschlossen ist, für das er 
die Sounds überträgt (z.B. MT32 oder CZ XXXX bei einigen Ad- 
ventures). 

$F0 zeigt an, daß jetzt System Exclusive Daten kommen 

$F7 das keine real Time Daten übertragen werden 

ein Byte für den Hersteller z.B. $41 ROLAND, $23 YAMAHA 

$0 - $F MIDI Kanal, auf dem die kommenden Daten empfangen 

werden 


Die dazwischen liegenden Bytes sind den Herstellern entsprechen¬ 
der Geräte überlassen, Informationen dazu sind entweder in den 
Anleitungen der Geräte oder eben bei dessen Herstellern erhältlich. 


$F7 zeigt das Ende der Übertragung von exclusiv Daten an 


5.3.9 Der MIDI Sample Dump Standard 

Gerade für Benutzer eines Falcon dürfte dieser Standard in Sachen 
Klangdatenübertragung sehr interessant sein, läßt sich doch auf 
diesem Weg ein komplettes Sample von jedem beliebigen Sampler, 
für viele gibt es große Soundbibliotheken, in den Falcon, und das 
ohne Qualitätseinbußen, die durch direktes Absamplen am Audio 
Ausgang des Samplers in Kauf genommen werden müssen, in den 
Falcon übernehmen. 

Es gibt im Prinzip zwei Möglichkeiten, die Daten zu übertragen, 
zum einem im Handshake, d.h. daß der Computer und der Sampler 
über zwei MIDI Kabel miteinander verbunden sind. Man gibt dem 
Sampler die Anweisung, den Sample zu senden und der Computer 
verarbeitet dann die Daten, wobei nur ein MIDI Kabel nötig ist. 
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Im Handshake sieht die Übertragung in etwa so aus: 

Computer "fragt" 

$F0 => Sytemexklusiv , $7E => kein realtime dann ein Byte MIDI 
Kanal 

2 Byte mit niederwertigem und dann höherwertigen 7 Bit der 
Samplenummer 

$F7 Ende der Übertragung 

Sampler "antwortet" mit 21 Bytes langem Sample Header 
$F0, $7E 

ein Byte MIDI Kanal 

2 Byte mit niederwertigem und dann höherwertigen 7 Bit der 
Samplenummer 

1 Byte, Format des Sample, 8 bis 28 Bit 

3 Bytes mit der Periode des Samples in nano =10‘ 9 s natürlich im 
üblichen 7 Bit pro Byte, mit dem niederwertigen Byte zuerst. 

3 Byte für die Länge des Samples (7 Bit pro Byte) 

3 Bytes Loop Start Punkt (7 Bit pro Byte) 

3 Bytes Loop Endpunkt (7 Bit pro Byte) 

1 Byte Looprichtung, 0 = vorwärts /1 = rückwärts 

$F7 Ende... 
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Computer antwortet: 

$F0, $7E, MIDI Kanal, $7F 

1 Byte Paketnummer (7 Bit), wenn die Nummer > 127 ist, fängt 
diese wieder mit 0 an. Bei einem Fehler bei der Übertragung der 
folgenden 120 Daten (7 Bit) Bytes mit Sampledaten kann man mit 
Hilfe dieses Datenbytes das Paket nochmals anfordern. 

$F7 Ende... 

Sampler sendet: 

$F0, $7E, MIDI Kanal, $02, Paketnummer 

120 Byte Sampledaten = ein Paket, dessen Format etwa so aus¬ 
sieht: 

z.B. 12 Bit 

MID LOW 

%0nnnnnnn %0nnnnn00 

oder 16 Bit 

HIGH MID LOW 

%0nnnnnnn %0nnnnnnn %0nn00000 

1 Prüfbyte, XOR aller Daten zwischen $F0 und diesem Byte 

$F7 Ende... 
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Computer gibt darauf entweder: 

Acknowledge, wenn alle Daten stimmen 

$F0, $7E, MIDI Kanal, $7F, nächste Paketnummer, $F7 

oder 

$F0, $7E, MIDI Kanal, $7F, letzte Paketnummer, $F7 
wenn die Daten nicht korrekt übertragen wurden, 
usw. 

Wenn man die Übertragung vorzeitig beenden möchte, sendet man 
Cancel, 

$F0, $7E, MIDI Kanal, $7D, Paketnummer, $F7 

Wenn Sampler und Computer nur mit einem MIDI Kabel verbunden 
sind (also kein Handshake erfolgt), wartet der Sampler zwei Se¬ 
kunden auf eine Antwort und sendet dann weiter! 

Das wars! 
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B.6. Der Aufbau wichtiger Pixelgrafik-Formate 

Für den Spieleprogrammierer ist das Importieren von Grafik eine 
der wichtigsten Aufgaben überhaupt, denn kaum eine Gattung von 
Spielen kommt so ganz ohne Grafik aus. Nun, es ist für den Hobby 
- Programmierer nicht immer ganz so einfach, die mit einem Stan¬ 
dard-Zeichenprogramm entwickelten Bilder in das eigene Pro¬ 
gramm einzubinden, denn diese sind meist gepackt, enthalten einen 
Header mit Daten zu Format, Palette u.v.m. . Aus diesem Grund 
möchte ich hier die für den Spieleprogrammierung wichtigsten Bild¬ 
formate beschreiben. 


6.1 Komprimierung bzw. Dekomprimierung von 
Bilddaten 

Packen u. Entpacken von Daten ist ein komplexer Themenbereich, 
daher möchte ich hier dem Leser einen kurzen Überblick verschaf¬ 
fen, um dann bei den Bildformaten genauer auf die einzelnen Ver¬ 
fahren eingehen zu können. Die hier besprochenen Packverfahren 
sind allesamt verlustfreie Packverfahren, d.h. “solche Hämmer wie 
'JPEG’ habe ich mir erspart". Verlustfrei bedeutet, daß man nach 
dem Auspacken genau das Gleiche erhält wie das, was man einge¬ 
packt hat. 

Nun, was heißt überhaubt 'packen’ ? 

Packen ist ein Verfahren um die Menge der anfallenden Daten zu 
reduzieren. Gerade bei Bildern ist das Packen eine effiziente Me¬ 
thode um den Massenspeicher ein klein wenig zu entlasten. So las¬ 
sen sich Bilder meist bis auf weniger als die Hälfte ihrer Länge 
komprimieren. Das liegt an den vielen gleichfarbigen Teilen oder oft 
vorkommenden Mustern aus denen ein Bild besteht, solche gleiche 
oder ähnliche Datenstrukturen lassen sich extrem gut zusammen¬ 
packen. Dazu wird ein Algorithmus entworfen, der die Bilder co¬ 
diert und dabei die gleichen oder ähnlichen Daten in einer Struktur 
zusammenfaßt. 
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Es gibt unzählige Verfahren, Daten zu packen, die teilweise stark 
an die zu packenden Daten angepaßt wurden. Hier zwei der ge¬ 
bräuchlichsten. 


6.1.1 Run length Compression bzw. Run Lengt Encoding 
(RLE) 

’Run length Compressien’ wird in vielen Bild-Formaten 
(mit)verwendet, z.B. IFF, Degas Elite (PC1-PC3), IMG, STAD 
(.PAC), Spectrum 512 (SPC), PCX, MSP u.v.m. 

Die einfachste Art der RLE ist, einfach die Menge der gleichen 
Punkte durch z.B. 1 Byte Länge und 1 Byte Farbe zu codieren. Al¬ 
lerdings ist das wenig effizient, da an vielen Stellen im Bild mehrere 
andersfarbige Pixel hintereinander kommen, daher wird RLE meist 
in leicht abgewandelter Form oder mit anderen Verfahren zusam¬ 
men verwendet. 


6.1.2 Das Lempe-Ziv Welsh Verfahren (LZW) 

Das LZW-Verfahren basiert auf dem Prinzip, das nicht Zeichen 
sondern Kompression (LZW) Codes übertragen werden. Die zu 
übertragenen Zeichen werden in einer String Tabelle Codes zuge- 
ordet. Dieses Verfahren ist sehr leistungsfähig und wird unter an¬ 
derem für Compuserves ".GIF "Format verwendet. 
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6.2. Aufbau der File Formate 

6.2.1 Neochrome 

Header (Formatkopf) 

Byte: 


CO 

o 

1 

o 

nicht definiert 

$4 - $23 

16 Worte Palette, also genau so wie es’setpalette’ 
(XBIOS 4) akzeptiert, es ist auf dem STE/TT/Falcon 
möglich, das niederwertige Bit zu setzen und somit aus 
4096 Farben auszuwählen, obwohl die mir bekannten 
NEOCHROME - Versionen das Auswahlen aus so vie¬ 
len Farben nicht unterstützen, stellen sie alle 4096 Far¬ 
ben dar, da die 16 Worte wohl unmaskiert in die Farb- 
register übertragen werden. 

$24 - $30 

nicht definiert. 

$31 

höherwertiges Nibble (4 Bit) Startfarbe der Paletten¬ 
animation Nibble (4 Bit) Endfarbe der Palettenanimati¬ 
on 

$32 - $34 

Geschwindigkeit der Palettenanimation, angegeben in 
der Anzahl der aufgebauten Monitorbilder (VBL’s) 
50/60 Hz zwischen den Änderungen der Palette. 

$35 - $7F 

nicht definiert 


32000 Byte Bildschirm 

Danach kommt immer ein 16 Farben 320*200 Bild und zwar mit 
dem Aufbau des Bildschrimspeichers in der niedrigen Auflösung. 
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6.2.2 Degas Elite 

Byte: 

$0 - $1 Auflösung: 0=niedrig; 1=mittel; 2=hoch 

ist Bit 15 gesetzt, sind die Bilddaten komprimiert 

$2 - $22 16 Worte Farbpalette 

dann folgen die Bilddaten, wenn unkomprimiert 32000 Bytes im 
Bildschirmspeicher Format 

gefolgt von 

4 Worten linke Begrenzungen für die 4 Farbanimationskanäle 
4 Worten rechte Begrenzungen für die 4 Farbanimationskanäle 
4 Worten Richtungsflag für die 4 Farbanimationskanäle 
4 Worten Zeitverzögerung für die 4 Farbanimationskanäle 

Komprimierung RLE (siehe auch Targa und IFF Format) 

Dekomprimierung: (einer Bitplane) 

1. Länge d. Bilddaten = Länge d. Bilddaten -1, falls Länge 0 ENDE 

2. Nehme Byte aus Bilddaten 

3. Falls Signed Byte >=0 gehe zu 7. 

4. Falls Byte =$80 gehe zu 1. 

5. copiere Byte * nächstes Byte aus Bildaten in den Bildspeicher 

6. gehe zu 1. 

7. lösche Bit 7 in Byte 

8. Länge der Bilddaten = Länge d. Bilddaten -1 

10. Kopiere Byte kommenden Bytes in den Bildschimrspeicher 

11. gehe zu 1. 

Bei Farbauflösungen (320*200*4 und 640*200*2) wird Zeile für Zeile 
decomprimiert. Wobei die Bitplanes wie beim IFF-Format zeilen¬ 
weise hintereinander angeordnet sind und auch genauso kompri¬ 
miert sind. 
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6.2.3 TARGA 

Das Targa Format ist extrem flexibel und wird hauptsächlich bei 
True Color Bildern verwendet. 

Achtung ! die hier angegebenen Wörter sind im "Little Endian For¬ 
mat" angegeben, d.h. in einem Wort befindet sich erst das nieder- 
dann höherwetiges Byte. Woran man merkt, daß dieses Format 
aus der PC - Welt stammt. 

Byte: 

$0 - $11 Header 

$0 identjen, Länge eines Kommentar Blocks 

$1 cmap_type, wenn 1 Palette sonst RGB 

$2 - $3 cmap_origin, Lage von color 0 in Palette 

$4 - $5 cmapjen, Anzahl der Farben in Palette z.B. 256 
$6 centry_size, Bittiefe der Palette 

$7 - $8 image_xorg, X - Wert von links unten 

$9-$10 image_yorg, Y - Wert von links unten 

$11 - $12 image_width, Breite des Bildes in Punkten 
$13 - $14 image_height, Höhe des Bildes in Punkten 
$15 pixel_size, Anzahl der Bits pro Pixel 

16, 24, 32 Bits 

$17 

$18-$19 image_discr, weitere Informationen zum Bildaufbau, 
normalerweise 0 

sonst 

Bits 0 - 3 Attribut Bits pro Pixel (Füllbits) 

Bit 4 immer 0 

Bit 5 0 = Ursprung in der linken unteren Ecke. Aufbau des 

Bildes von links nach rechtsund von unten nach oben 
1 = Ursprung in der linken oberen Ecke. Aufbau des 
Bildes von links nach rechts und von oben nach unten 
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Bit 6 - 7 00 Die Zeilen folgen nacheinander 

01 Erst die geraden dann die ungeraden Zeilen 

10 Die Bildzeilen werden in vier Blöcke 
unterteilt, {0, 4, 8,...} {1,5, 9,...} 

{2, 6,10, ...} {3, 7,11,...} 

11 Reserviert 

Kommentar Block, bis zu 255 Bytes lang 

Palette, falls erforderlich, in folgendem Format: 

bei 32 Bit 4 Byte pro Eintrag “BGRX" 
bei 24 Bit 3 Byte pro Eintrag "BGR" 

bei 16 Bit 2 Byte pro Eintrag, %Xrrrrrgg gggbbbbb (Intel Format) 

Bildinformationen: 

Der Aufbau der Farbpalette entspricht bei einem Bild ohne Palette 
(direct color) dem Pixelformat. 

Komprimierung RLE 

Byte = %innnnnnn 

%nnnnnnn = menge-1 

i = ID Bit, wenn gesetzt komprimiert, sonst folgen 

%nnnnnnn+1 Bytes unkomprimierte Daten 

Wenn also das ID Bit gesetzt ist wird die folgende Information über 
die Pixelfarbe oder Farbnummmer in der Palette %nnnnnnn+1 mal 
auf den Bildschirm gebracht. Wenn nicht, werden die nächten 
%nnnnnnn+1 Pixelfarbwerte oder Farbnummern in der Palette auf 
den Bildschirm gebracht. 
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6.2.4 IFF (Interchange File Format) 

In diesem Format findet man auf dem AMIGA und gelegentlich auch 
auf dem PC Bilder, Animationen und Samples. Auf dem ST wird 
dieses Format auch von einigen Programmen, wie z.B. Deluxe 
Paint 2 unterstüzt. Dieses Format wurde von Electronic Arts für 
die damals neuen AMIGA entwickelt und hat sich diesem Gerät 
schnell zum Standard entwickelt. 

Das Konzept, das hinter den IFF Dateien steht, ist, ein leicht er¬ 
weiterbares Dateiformat zu sein, das für alle möglichen Datentypen 
verwendet werden kann. Das hat man durch die sogenannten 
Chunks gelöst. 

Ein Chunk ist ein Datenblock, dieser Block kann alle mögliche Da¬ 
tentypen Enthalten, welcher üblicherweise mit einer Identifikation 
(ID) beginnt. 

So ein ID ist ein Reihe von 4 ASCII Zeichen, also genau einem 
Langwort (was es dem Maschinenprogrammierer leichter macht), 
das die einzelnen Blöcke (Chunks) einer IFF Datei kennzeichnet 
und voneinander abtrennt. 

Nach der ID folgt ein Langwort mit der Länge der Daten im Chunk 
und dann die Daten. 

Wenn man also eine IFF Datei lesen möchte, muß man sich von 
Chunk zu Chunk hangeln, in dem man die ID eines Chunks prüft 
und, falls es sich nicht die gewünschten Daten handelt, den Daten¬ 
block überspringt und das nächste ID testet. Denn mehrere Bild-, 
Sample-, Text- etc. Blöcke können sich in einer einzigen Datei be¬ 
finden. 
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Die üblichen Chunks einer IFF Bilddatei: 


ID 

"FORM" leitet ein Objekt ein (z.B. Bilddatei), gefolgt von einem 
Langwort mit der Länge des Objekts und ein ID für die Art des Ob¬ 
jekts 

ILBM = InterLeaved BitMap (Bilddatei) 

8SVX = 8 Bit Sampled Voice (Sample) 

ANBM = ANimated Bitmap 

GSCR = General use musical SCore 

PICS = Macintosh PICture 

USCR = Uhuru sound Software musical ScoRe 

UVOX = Uhuru sound Software Macintos VOice 

SMUS = Simple MUSic Score 

VDEO = deluxe video Construction Srt ViDEO 

u.v.m 

"BMHD" BitMap HeaDer (Bildformat) 

1 Langwort - Länge des Chunks 
1 Wort Breite des Bitmapausschnitts 
1 Wort Höhe des Bitmapausschnitts 
1 Wort X Position der Bitmap auf der Grafikseite (meist 0) 

1 Wort Y Position der Bitmap auf der Grafikseite (meist 0) 

1 Byte Menge der Bitplanes 
1 Byte Maske, 0 = keine Maske 

1 = Maske als Plane im Body Chunk 

2 = Bild durchsichtig wo transparent Color 

3 = alle Pixel außerhalb des Umrisses transparent 
1 Byte komprimiert, 1 = komprimiert 

1 Byte reserviert 
1 Byte transparent Color 
1 Byte Pixel ratio x, Pixelgrößenverhältnis X 
1 Byte Pixel ratio y, zu Pixelgrößenverhältnis Y 
1 Wort Breite der Grafikseite 
1 Wort Höhe der Grafikseite 
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"CMAP" ColorMAP (Palette) 

1 Langwort - Länge des Chunks 

Die Palettedaten werden immer auf 8 Bit pro Farbe ausgelegt. Das 
bedeutet, daß sich die 4096 Farben des STE alle im höherwertigen 
Nibble (4 Bit) der jeweiligen Farbkomponente. 

z.B. eine STE Palettenregister mit 


rot = 12, grün = 5, blau = 1 

erzeugt folgende 3 Bytes eines IFF Paletteneintrags 
RGB 
1. Byte = 192, 2. Byte = 80, 3. Byte = 16 


"BODY" 

1 Langwort - Länge des Chunks 
Entpacken von IFF Planes und Zeilen: 

Das Entpacken funktioniert wie beim Targa Format, allerdings sind 
die Bilddaten bei IFF planeweise und nicht pixelweise wie im Targa 
Format organisiert. 

Aufbau einer Zeile: 

1. Zeile - Plane 1 
1. Zeile - Plane 2 


1. Zeile - Plane n 






4 
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B.7. Nutzen des DSP 56001 

bei der Spieleprogrammierung 

Leider hatte ich den F030 nur etwa 3 Wochen zu Verfügung, einer 
jener Modelle, die von ATARI einigen Händlern als Vorführgerät 
geliefert wurde. Exakt das Modell, das auch in einigen Zeitungen 
von innen zu bewundern war (ST Computer, ATARI Journal etc.). 
Ich konnte mich daher nicht allzu lange mit dem DSP beschäftigen, 
auch weil der Falcon noch andere faszinierende Geheimnisse ver¬ 
barg, die erforscht werden mußten. 

Ich kann hier nur einen kurzen Überblick über die Programmierung 
des DSP bieten, somit ist dieses Kapitel auch mehr zum Nach¬ 
schlagen gedacht, weitere Informationen sind dem "DSP 56000/1 
Users Manual“ von MOTOROLA zu entnehmen, mehr würde den 
Rahmen des Buches sprengen und wäre höchstens eine Idee für 
ein weiteres Buch. 


7.1 Was ist ein Signalprozessor ? 

Ein Signalprozesssor ist ein Prozessor, der im Befehlssatz und 
seinen Ausführungszeiten für die Aufgaben der Signalverarbeitung 
(Filtern, Interpolieren u.v.m.) optimiert wurde. 


7.2 Die Architektur des DSP 

Der DSP 56001 ist im Falcon030 mit 32MHz getaktet und hat 96kB 
eigenes statisches RAM, auf das er, ohne Wartezyklen einlegen zu 
müssen, zugreifen kann. Er ist damit wesentlich schneller als ein 
16MHz getaktete 68030, der sich im Falcon befindet. Er besitzt ei¬ 
ne dreistufige Pipeline und kann unter bestimmten Bedingungen 
Befehle parallel ausführen. 
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7.2.1 Das Buskonzept 

Prinzipiell ist der DSP schon ein Computer in sich, mit Schnittstel¬ 
len, Bus, RAM und ROM. Im Gegensatz zur 68000er Familie be¬ 
sitzt der DSP Harvard-Architektur, so sind Daten und Programm¬ 
speicher getrennt. Der DSP kennt drei Arten von Speicher, X Da¬ 
tenspeicher, Y Datenspeicher und P Programmspeicher. Die er¬ 
sten 512*24 Bit von X und Y Datenspeicher sind jeweils ROM und 
die folgenden 512*24Bit Bytes sind jeweils RAM. Erweitern läßt 
sich der X- als auch der Y-Speicher, extern bis aus 64k*24 Bit. Der 
Programmspeicher des DSP 56001 besteht aus 512*24 Bit RAM 
Speicher; dieser läßt sich ebenfalls extern auf 64k*24 Bit erweitern. 
Im Falcon030 hat ATARI den DSP mit 32K*24 Bit externem RAM 
erweitert. ATARI benutzt das externe 32k*24 Bit RAM sowohl für 
X- und Y- also auch für P- RAM, so daß diese sich überschneiden. 
Somit ist der Zugriff auf externes RAM im DSP, zumindest teilwei¬ 
se, wieder wie bei den Rechnern mit von Neumann Architektur 
(Daten und Programm in einem Speicher). 


DSP Speicher in Falcon030 

$ffff 


|7fff 


|3fff 


feiff 


|0080 


Reseruiert 


16K 

gespiegelt 


16K 

EHternes 

RRfl 


internes 

RRfl/ROfl 


Reserviert 


16K 

gespiegelt 


16K 

Enternes 

RRfl 


internes 

RRPI/ROfl 


Reserviert 


32K 

Progrann 

RRfl 

überloger t 

K Speicher 

über lagert 

V Speicher 

internes 

RRfl 



H Speicher 


V Speicher p Speicher 
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7.2.2 Die Interruptvektoren des DSP 

ln den ersten 64*24 Bit des DSP-Programmspeichers befinden sich 
die Interrupt Vektoren. 

Beginnend an der Adresse P:$0000 oder P:$E000 

Offset IPL Interrupt Geber 

0 3 Hardware Reset 

2 3 Stack Error 

4 3 T race 

6 3 SWI (Software Interrupt) ähnl. TRAP beim 68000 


8 

0-2 

IRQA Externer Interrupt 

A 

0-2 

IRQB Externer Interrupt 

C 

0-2 

SSI empfängt Daten 

E 

0-2 

SSI empfängt Daten (Exception Status) 

10 

0-2 

SSI sendet Daten 

12 

0-2 

SCI sendet Daten (Exception Status) 

14 

0-2 

SCI empfängt Daten 

16 

0-2 

SCI empfängt Daten (Exception Status) 

18 

0-2 

SCI sendet Daten 

1A 

0-2 

SCI wartet 

IC 

0-2 

SCI Timer 

IE 

3 

NMI (nicht maskierbarer Interrupt) extern 

20 

0-2 

Host empfängt Daten 

22 

0-2 

Host sendet Daten 

24 

0-2 

Host Befehl (voreingestellt) 

26 

0-2 

als Host Befehl möglich 

28 

0-2 

als Host Befehl möglich 

2A 

0-2 

als Host Befehl möglich 

2C 

0-2 

als Host Befehl möglich 

2E 

0-2 

als Host Befehl möglich 

30 

0-2 

als Host Befehl möglich 

32 

0-2 

als Host Befehl möglich 

34 

0-2 

als Host Befehl möglich 

36 

0-2 

als Host Befehl möglich 

38 

0-2 

als Host Befehl möglich 

3A 

0-2 

als Host Befehl möglich 

3C 

0-2 

als Host Befehl möglich 

3E 

0-2 

Illegaler Befehl 


Achtung ! der SCI-Port und die SCI-Register sollen laut ATARI bei 
DSP Software auf dem F030 nicht verwendet werden. 
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7.2.3 Die I/O Register des DSP 

Die Adressen sind wie beim DSP üblich wortweise, also in 24 Bit- 
Schritten angegeben. 

X:$FFCO bis X:$FFDF Reserved 


X:$FFEO 

X:$FFE1 

X:$FFE2 

X:$FFE3 

X:$FFE4 

X:$FFE5 

X:$FFE6 

X:$FFE7 

X:$FFE8 

X:$FFE9 

X:$FFEA 

X:$FFEB 

X:$FFEC 

X:$FFED 

X:$FFEE 

X:$FFEF 

X:$FFFO 

X:$FFF1 

X:$FFF2 

X:$FFF3 

X:$FFF4 

X:$FFF5 

X:$FFF6 

X:$FFF7 

X:$FFF8 

X:$FFF9 

X:$FFFA 

X:$FFFB 

X:$FFFC 

X:$FFFD 

X:$FFFE 

X:$FFFF 


Port B - Bus Control Register (PBC) 

Port C - Control Register (PCC) 

Port B - Data Direction Register (PBDDR) 
Port C - Data Direction Register (PCDDR) 
Port B - Data Register (PBD) 

Port C - Data Register (PCD) 

Reserved 

Reserved 

Host Control Register (HCR) 

Host Status Register (HSR) 

Unbenutzt 

Host Receive/Transmit Register (HRX/HTX) 

SSI Control Register A (CRA) 

SSI Control Register B (CRB 

SSI Status/Time Slot Register (SR/TSR) 

SCI Receive/Transmit Register (RX/TX) 

SCI Interface Control Register (SCR) 

SCI Interface Status Register (SSR) 

SCI Control Register (SCCR) 

SCI Transmit Data Address Register (STXA) 

SCI LOW-REC/XMIT Data Register (SRX/STX) 

SCI MID-REC/XMIT Data Register (SRX/STX) 

SCI HI-REC/XMIT Data Register (SRX/STX) 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Reserved 

Port A - BUS Control Register (BCR) 

Interrupt Priority Register (IPR) 
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7.3. Programmierung des DSP 

7.3.1 Die Register des DSP 

Register zur Adressierung 

Die Adress-Erzeugungs-Einheit (AGU) des DSP besteht aus zwei 
Arithmetisch Logischen Einheiten (ALU). Jede ALU hat ihre ihr ei¬ 
gens zugeordneten Register und kann bei Verwendung dieser Re¬ 
gister parallel zur zweiten ALU 16 Bit Adressberechnungen vor¬ 
nehmen. Es ist aber auch möglich, für eine ALU die Register der 
anderen mitzubenutzen, was dann eine Parallelverarbeitung beider 
ALU’s ausschließt. 

LOW ADDRESS ALU 

R0-R3, 16 Bit Adressregister N0-N3, 16 Bit Offset Register 
M0-M3, 16 Bit Modifizier Register 

HIGH ADDRESS ALU 

R0-R7, 16 Bit Adressregister 

N0-N3, 16 Bit Offset Register 

M0-M3, 16 Bit Modifizier Register 

Datenregister 

X , 56 Bit bestehend aus 

X0&X1,24 Bit Datenregister 

Y , 56 Bit bestehend aus 

Y0&Y1,24 Bit Datenregister 
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Akkumulatoren 

A , 56 Bit bestehend aus 

AO, 24 Bit Akku 
AI, 24 Bit Akku 
A2, 8 Bit Akku 

B, 56 Bit bestehend aus 

BO, 24 Bit Akku 
Bl, 24 Bit Akku 
B2, 8 Bit Akku 


Programm Kontroll Register 

LA, LOOP Adresse bzw. Adresse des letzten Befehls im LOOP 
LC, LOOP Zähler - Menge der Wiederholungen (auch für REP) 

OMR, 8 Bit Operating Mode Register 

SR, Status Register, bestehend aus CCR - 8 Bit und MR - 8 Bit 

SP, 6 Bit Stackpointer 

System Stack, bestehend aus 15*32 Bit internem Speicher aufge- 
teilt in SSH und SSL je 16 Bit breit. 
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7.3.2 Die Adressierungsarten des DSP 

Glücklicherweise ist der Syntax des DSP-Assemblers dem der 
68000er Familie in vielem ähnlich. 

Wordbreite des DSP: 

8 Bit = Byte 
16 Bit = Short Byte 
24 Bit = Word 
47 Bit = Long Word 
56 Bit = Accumulator 

S = Zugriff auf den System Stack 
C = Zugriff auf das Programm Controller Register 
D = Zugriff auf das Data ALU Register 
A = Zugriff auf Address ALU Register 
P = Zugriff auf den Programm Speicher 
X = Zugriff auf den-X Speicher 
Y = Zugriff auf den-Y Speicher 
L = Zugriff auf den-L Speicher (48 Bit von/zu X: und Y:) 

XY = Zugriff auf X&Y Speicher (24 Bit je von/zu X: und Y:) 


Register direkt 

a) Daten oder Kontroll Register direkt (nur C, D) 
MOVE XI ,LC ; Kopiere XI nach LC 

b) Adress Register direkt (nur a) 

MOVE R1,R2 ; kopiere RI nach R2 

c) Adress, Offset Register direkt (nur a) 

MOVE RI ,N1 ; kopiere RI nach NI 

d) Adress, Modifizier Register direkt (nur a) 

MOVE R2,M3 ; kopiere R2 nach m3 
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Adress Register Indirekt 

e) Adress Register indirekt 

möglich für P, X, Y, L, XY 

MOVE AI ,X:(R0) ; Inhalt von AI in Adresse worauf RO zeigt 

f) Adress Register indirekt mit postincrement (+1, danach) 
möglich für P, X, Y, L, XY 

MOVE B0,Y:(R1)+ ; BO an Adresse RI dann R1=R1+1 

g) Adress Register indirekt mit postdecrement (-1, danach) 

möglich für P, X, Y, L, XY 

MOVE Y0,Y:(R3)- ; YO in Adresse R3 dann R3=R3-1 

h) Adress Register indirekt mit postincrement Offset Register 

möglich für P, X, Y, L, XY 

MOVE XI ,X:(R2)+N2 ; XI in Adresse R2 

; dann R2=R2+N2 

i) Adress Register indirekt mit postdecrement Offset Register 
möglich für P, X, Y, L 

MOVE X:(R4)-N4,A0 ; Inhalt von Adresse R4 in AO 

; dann R4=R4-N4 
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j) Adress Register indirekt mit Offset Register als Index 

möglich für P, X, Y, L 

MOVE Y1 ,X:(R6+N6) ; Inhalt von Y1 in Adresse (R6+N6) 

k) Adress Register indirekt predekrement (-1, davor) 

möglich für P, X, Y, L 

MOVE X:-(R5),B1 ; R5=R5-1, Inhalt von R5 in Bl 

SPECIAL 


l) Konstanten Adressierung (nur in P:) 

MOVE #$123456,AO ; Konstante in 24 Bit Register 
MOVE #$123456,A ; Konstante in 56 Bit Register 
MOVE #$801234,A ; negative Konstante in 56 Bit Register 

m) Konstanten Adressierung - Short Byte (nur in P:) 


MOVE #$FF,A1 
MOVE #$1 F,Y1 
MOVE #$1 F,A 
MOVE #$83,B 


; Konstante in z.B. A1,A2,B0,B2,Rn,Nm 
; positive Konstante in z.B. X0,X1 ,Y0,Y1 ,A,B 
; positive Konstante in z.B. X,Y,A,B 
; negative Konstante in z.B. X0,X1,Y0,Y1,A,B 


n) Absolute Adressierung (nur in P:) 

MOVE Y:$5432,B0 ; Inhalt von $5432 in BO 
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o) Absolute Adressierung - Short Address (in P:, X:, L:) 

Die Adresse des Operanden darf nicht größer als 6 Bit sein. Die 
Adresse wird mit Nullen auf 16 Bit erweitert, wenn ein Operand 
oder Programmspeicher adressiert wird. 

MOVE P:$3200,X0 
MOVE A1,X:$3 


p) Short Jump Address, springe zu mit 12 Bit angegebener Adresse 

JMP $123 ; Adresse muß kleiner sein als $1000 

q) I/O Adressierung - short Address 

MOVEP AI ,X:«$FFFE ; Ziel darf hier nur von $FFC0 - $FFFF gehen 

r) Implicit Reference, ändern eines nicht angegebenen Registers 
Ein gutes Beispiel ist der ’REP’ Befehl, der den LC ändert. 


7.3.3 Übersicht der Befehle 

Ich kann hier nur eine kurze Übersicht bieten, eine ausführliche Er¬ 
klärung findet man im USER Manual von Motorola, wobei allein die 
Erläuterung des Befehlssatzes über 250 Seiten einnimmt. 
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Die Flags 

Die E, U, N, Z, V, und C Bits sind echte condition codes, sie wer¬ 
den je nach Ergebnis einer Operation der ALU gesetzt. Bei Adress- 
Berechnungen oder Datentransfer werden sie nicht verändert. Das 
L Bit (latching overflow bit) wird gesetzt, wenn ein Überlauf im Ac- 
cumulator auftrftt (wie auch das V Bit) oder beim Wandeln von 56 
Bit auf 24 Bit durch den Limiter. 

* wird gesetzt, je nach Ergebnis der ALU 
wird nicht verändert 

? wird nur in bestimmten Situationen gesetzt 
0 Das V Bit wird gelöscht 


Befehl 

Flags 

Notiz 

Funktion 

ABS 

LEUNZVC 

****** 


Absoluter Wert 

ADC 

* * * * * * * 


Addiere 48 Bit mit Übertr. 

ADD 

******* 

1 

Addiere 24 Bit 

ADDL 

***** 9 * 


Quelle + 2*Ziel 

ADDR 

******* 


Quelle + Ziel/2 

AND 

* __??o_ 

8,9 

logisches UND 24 Bit 

ANDI 

??????? 

2 

UND 8 Bit konst. mit Reg 

ASL 

***** 99 

1,3 

Accu nach links versch. 

ASR 

***** o? 

4 

Accu nach rechts versch. 

BCHG 

? 

5 

teste u. ändere Bit 

BCLR 

? 

5 

teste u. lösche Bit 

BSET 

? 

5 

teste u. setze Bit 

BTST 

? 

5 

teste Bit 

CLR 

***** Q 


lösche Akku 

CMP 

******* 


vergleiche 

CMPM 

******* 


vergl. ABS(Quelle),Ziel 

DIV 

* 9 ? 

8,9 

Divid. Ziel=quot.& rest 

DO 

* 


Starte Hardw. Loop 

ENDDO 

EOR 

*_ ??o_ 


Beende Loop 

Exklusive Oder 24 Bit 

ILLEGAL 


illegaler Befehl 
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Jcc 

JCLR 

JMP 

JScc 

JSCLR 

JSET 

JSR 

JSSET 



LSL 

*_??o? 

8,9,10 

LSR 

LUA 

*_??o? 

8,9,11 

MAC * 

***** 


MACR * 

r * * * * * 


MOVE 

* 


MOVEC 

??????? 

13 

MOVEM 

??????? 

13 

MOVEP 

??????? 

13 

MPY 

****** 


MPYR 

****** 


NEG 

NOP 

****** 


NORM 

★ ****/^ 

1 

NOT 

* _??0_ 

8,9 

OR 

* _??0_ 

8,9 

ORI 

??????? 

6 

REP 

RESET 

★ 


RND 

****** 


ROL 

*_??o? 

8,9,10 

ROR 

* ??o? 

8,9,11 

RTI 

??????? 

12 

RTS 

* 


SBC 

STOP 

******* 


SUB 

******* 

1 

SUBL 

* * * * */^ * 


SUBR 

SWI 

******* 



springe wenn cc 
springe wenn Bit gelöscht 
unbedingter Sprung 
springe Unterpr. wenn cc 
springe sub. wenn cc gel. 
springe wenn Bit gesetzt 
springe zu Unterprogramm 
springe Unterpr. wenn Bit 
schiebe nach links 24 Bit 
schiebe nach rechts 24 Bit 
Load Updated Address 
Add. Multi, zu Accu. 

Add ger. Multi zu Accu. 
kopiere Quelle nach Ziel 
kopiere CR 

kopiere in P: oder von P: 
kopiere von/zu I/O mem. 
vorz. ger. Multi, 
runde Vorz. ger. Multi, 
negiere Accu. 

No Operation 
Normalize Accu. Iteration 
%1 -> %0 & %0 -> &1 
ODER 

ODER 8 Bit konst. mit Reg. 
wiederh. nächst. Befehl 
RESET DSP 
runde Akku. 

ROtate Left 24 Bit 
ROtate Right 24 Bit 
ReTurn from Interrupt 
ReTurn from Subroutine 
Subtrah. 56 Bit mit Übert. 
stoppt den Prozessor 
subtrahiere 24 Bit 
Quelle-2*Ziel 
Quelle-Ziel/2 
Software Interrupt 


310 
























Nutzen des DSP 56001 bei der Spieleproqrammierunq 


Tcc 

Übertrage wenn cc 

TFR 

Übertrage Akku. Akku 

tst ******* 

vergleiche Akku.s 

WAIT 

warte auf Interrupt 

Notiz: 



1 V wird gesetzt, wenn ein Überlauf bei einem 56 Bit Ergebnis. Es wird auch 
gesetzt, wenn das MS Bit des Ziels wegen eines shift left (z.B. ADDL, SUBL) 
geändert wurde. Ansonsten wird das V Bit gelöscht. 

2 ? wird gelöscht, falls das Ziel das CCR ist, wenn das korrespondierende Bit in 
der Konstante gelöscht ist. 

3 C wird gesetzt, wenn das Bit 55 der Quelle gesetzt ist. Sonst wird es gelöscht. 

4 C wird gesetzt, wenn das Bit 0 in der Quelle gesetzt ist. Ansonsten gelöscht 

5 C wird gesetzt, wenn das Bit #n in der Quelle gesetzt ist. Sonst gelöscht, 

6 ? Wird gesetzt, falls das Ziel das CCR ist, wenn das correspondierende Bit 
der Konstante gesetzt ist. Ansonsten bleibt das Bit wie es ist. 

7 C wird gesetzt, wenn Bit 55 des Ergebnisses gelöscht ist. Ansonsten wird es 
gelöscht. 

8 N wird gesetzt, wenn Bit 47 des Ergebnisses gesetzt ist. Sonst wird es ge¬ 
löscht. 

9 Z wird gesetzt, wenn die Bits 24 - 47 Null sind. Sonst wir es gelöscht. 

10 C wird gesetzt, wenn Bit 47 der Quelle gesetzt ist. Ansonsten gelöscht. 

11 C wird gesetzt, wenn Bit 24 der Quelle gesetzt ist. Sonst gelöscht. 

12 ? wird je nach Wert, der vom Stack geholt wurde, gesetzt. 

13 ? wird gesetzt nach den korrespondierenden Bits der Quelle, wenn das Status 
Register (SR) das Ziel ist. Wenn SR nicht das Ziel ist , wird das L Bit, wenn 
ein Wert abgeschnitten wurde, gesetzt. Ansonsten werden die ? Bits nicht ver¬ 
ändert. 
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CONDITON CODE I BEDEUTUNG I CCR 


cc 

Carry Clear 

C=0 

cs 

Carry Set 

C=1 

EC 

Extension Clear 

E=0 

EQ 

EQual 

Z=1 

ES 

Extension Set 

E=1 

GE 

Greater or Equal 

(N eor V) = 0 

GT 

Greater Than 

Z or (N eor V)=0 

HS 

Higher or Same 

C=0 

LC 

Limit Clear 

L=0 

LE 

Less or Equal 

Zor (N eor V)=1 

LS 

Limit Set 

L=0 

LT 

Less Than 

(N eor V) = 1 

Ml 

Minus 

N=1 

NE 

Not Equal 

Z=0 

NR 

NoRmalized 

Z+(not U and not E)=1 

PL 

Plus 

N=0 

NN 

Not Normalized 

Z+(not U and not E)=0 
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7.4 Ansteuern des DSP’s über das Betriebssystem 

Hier folgen die Systemaufrufe, die ATARI zur Programmierung des 
DSP ins Falcon-TOS implementiert hat. 

Nomenklatur: 

BYTE = 8 Bit 
WORD = 16 Bit 
LONG = 32 Bit 

VOID = Dummy, d.h. keine Rückgabe 
* = Zeiger auf 

Rückgabe erfolgt in DO 

Beispiel: 

XBIOS 110 

VOID DSP_ExecBoot(LONG ‘codeptr, LONG codesize, 

WORDability) 

ist 


move.w 

#ability,-(sp) 

move.l 

#codesize,-(sp) 

pea 

codeptr 

move.w 

#110,-(sp) 

trap 

#14 

lea 

12(sp),sp 
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7.4.1 Daten Transfer Routinen 

XBIOS 96 

VOID Dsp_DoBlock( LONG *data_in, LONG sizejn, 

LONG *data_out, LONG size_out) 

Diese Funktion dient zum Übertragen von Daten zwischen den 
Prozessen auf der CPU und dem DSP. 

*data_in , Feld mit den zu übertragenden Daten als Inhalt 
sizejn , Menge 64K der zu übertragenden DSP Wörter 
*data_out, freies Feld für Daten vom DSP 
size_aut , Menge 64K der vom DSP zu übertragenden DSP 
Wörter 


XBIOS 97 

VOID Dsp_BlkHandShake( LONG *datajn, LONG sizejn, 

LONG *data_out, LONG size_out) 

Diese Funktion dient zum Übertragen von Daten zwischen den 
Prozessen auf der CPU und dem DSP. Ist also identisch zur 
Dsp_DoBlock() bis auf die Art der Übertragung, die in diesem Falle 
im Handshaking erfolgt. 

*datajn , Feld mit den zu übertragenden Daten als Inhalt 
sizejn , Menge 64K der zu übertragenden DSP Wörter 
*data_out , freies Feld für Daten vom DSP 
size_aut , Menge 64K der vom DSP zu übertragenden DSP 
Wörter 
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XBIOS 98 

VOID Dsp_Blkünpacked( LONG *data_in, LONG sizejn, 

LONG *data_out, LONG size_out) 

Noch eine Routine zum Übertragen von Daten zwischen DSP und 
CPU Prozessen. Bei diesem Befehl werden die DSP Wörter als 
Langwörter übertragen, d.h. Dsp_GetWordSize muß 4 sein. Wenn 
die übertragenen DSP Wörter < 4 sind, ist der Inhalt der nicht 
übertragenen Teile des Langworts nicht definiert. 

*datajn , Feld mit den zu übertragenden Langwörtern 

sizejn , Menge 64K der zu übertragednen DSP Wörter 

*data_out, freies Feld für Langwörter vom DSP 

size_aut , Menge 64K der vom DSP zu übertragenden Langwörter 


XBIOS 99 

VOID DspJnStream( LONG *datajn, LONG block_size, 

LONG num_blocks, LONG *block_done ) 

Überträgt Daten zum DSP via Interrupt. Ein Interrupt zeigt an, daß 
der DSP bereit ist, Daten zu empfangen. Die Übertragung erfolgt 
nicht per Handshake, sondern die Funktion liefert bei jedem DSP- 
Interrupt Daten zum DSP. 

datajn , Zeiger auf zu übertragende Blöcke 
block_size , Menge der pro Block zu übertragenden DSP Wörter 
num_blocks , Menge der zu übertragenden Blocks 
block_done , Zeiger auf eine Variable, in die bei Beendigung hinein¬ 
geschrieben wird, wieviel Blöcke übertragen wur¬ 
den 
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XBIOS 100 

VOID Dsp_OutStream( LONG *data_out, LONG block_size, 

LONG num_blocks, LONG *block_done) 


Ähnlich DspJnStream, mit dem Unterschied, daß die Daten von 
DSP kommen und nicht zu ihm übertragen werden. 

data_out .Zeiger auf ein Feld für ankommende Daten 
block_size , Menge der zu empfangenden DSP Wörter 
num_blocks, Menge der zu empfangenden Blocks 
block_done , Zeiger auf eine Variable, in die bei Beendigung 

hineingeschrieben wird, wieviel Blöcke übertragen 
wurden 


XBIOS 101 

VOID Dsp_IOStream( LONG *data_in, LONG *data_out, 

LONG blockjnsize, LONG block_outsize 
LONG num_blocks, LONG *block_done) 

Ähnlich DspJnstream, allerdings wird bei jedem zum DSP übertra¬ 
genen BLock ein Block vom DSP abgeholt. 

datajn , Zeiger auf zu übertragende Blöcke 
data_out , Zeiger auf ein Feld für ankommende Daten 
block_outsize , Menge der zu empfangenden DSP Wörter 
blockjnsize , Menge der pro Block zu übertragenden 
DSP Wörter 

num_blocks , Menge der zu empfangenden Blocks 
block_done , Zeiger auf eine Variable, in die bei Beendigung hin¬ 
eingeschrieben wird, wieviel Blöcke übertragen 
wurden 
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XBIOS 102 

VOID Dsp_Removelnterrupt(WORD mask) 

Funktion zum Ausschalten der DSP-Interrupts, sollte aufgerufen 
werden, wenn eine der "stream" Aufrufe weniger Daten als erwar¬ 
tet übertragen hat. 

mask, %XXXXXXtr 

r = kein Interrupt, wenn der DSP bereit ist zu empfangen 
t = kein Interrupt, wenn der DSP bereit ist zu senden 


XBIOS 103 

WORD Dsp_GetWordSize() 

Gibt die Größe eines DSP-Worts in Bytes zurück (momentan 3 
Bytes). Dieser Aufruf sollte auf jedem Fall vor der Benutzung von 
Datentransfer-Funktionen gemacht werden, um kompatibel zu 
kommenden ATARI Computern zu bleiben. 


XBIOS 123 

VOID Dsp_BlkWords( LONG *data_in, LONG sizejn, 

LONG *data_out, LONG size_out) 

Again, eine Routine zum Übertragen zwischen DSP und CPU Pro¬ 
zessen. Allerdings hier nur vorzeichenbehaftete 16 Bit Werte, die 
vorzeichenrichtig auf die Wortbreite des DSP erweitert werden. 
Vom DSP kommende Worte werden ebenso wieder auf signed 16 
Bit Werte gebracht, d.h. nur das mid&low Byte werden vom DSP 
übertragen. 

*data_in , Feld, mit den zu übertragenen Vorzeichen behafteten 
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16 Bit Worten 

sizejn , Menge 64K der zu übertragenden Wörtern 

*data_out , freies Feld mit Platz für die Wörter 

size_aut , Menge 64K der vom DSP zu übertragenden Wörter 


XBIOS 124 

VOID Dsp_BlkBytes( LONG *data_in, LONG sizejn, 

LONG *data_out, LONG size_out) 

Es reißt nicht ab, wiederum eine Routine zum Datenaustausch 
zwischen DSP und CPU Prozessen. Diesmal werden die Daten 
byteweise übertragen. 

*datajn , Feld mit den zu übertragenden Bytes 

sizejn , Menge 64K der zu übertragenen Bytes 

*data_out , freies Feld für Bytes vom DSP 

size_aut , Menge 64K der vom DSP zu übertragenden Bytes 


XBIOS 126 

VOID Dsp_SetVectors(LONG ‘receiver, LONG ’transmitter) 

Installieren eigener Interruptroutinen, zum Senden oder Empfangen 
vom/zum DSP. Wenn ’transmitter’ <> 0 die niederwertigen 24 Bit 
von ’transmitter’ werden zum DSP gesendet, ansonsten bekommt 
der DSP keine Meldung. Wenn beide Zeiger Null werden, werden 
keine Interruptroutinen installiert. 

receiver , Zeiger auf Routine zum Verarbeiten der vom DSP 
kommenden Daten 
0 = nicht installieren 

transmitter , Zeiger auf Routine zum Senden von Daten zum DSP 
0 = nicht installieren 
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XBIOS 127 

Diese Funktion kann im Prinzip das, was alle anderen Funktionen 
zuvor konnten. Allerdings kann man mit dieser Funktion mehrere 
Typen von Daten von/in unterschiedliche Speicherbereiche von/in 
den DSP übertragen. Um das zu koordinieren, muß eine Struktur 
angelegt werden, die Art, Menge und Ort wohin bzw. wovon die 
Daten kommen. Man spart sich mit diesem Aufruf unter Umstän¬ 
den viele Aufrufe der zuvor genannten Funktionen. 

VOID Dsp_MultBlocks( LONG numsend, LONG numreceive, 

LONG ‘sendblocks, LONG *receiveblocks) 

numsend , Menge der zu sendenden DSP Blockelemente 
numreceive , Menge der zu empfangenden DSP BLockelemente 
‘sendblocks , Zeiger auf eine Struktur der zu sendenden Daten 
*receiveblocks , Zeiger auf eine Struktur der zu empfangenden 
Daten 

Struktur: 

WORD blocktype , Art der Daten im Block 

0 = Langworte, 1 = vorzeichenbehaftete Worte 
2 = Bytes 

LONG blocksize , Menge der Elemente im Block 
LONG *blockaddr , Adresse des Blocks 
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7.4.2 Programm Kontroll Routinen 

XBIOS 104 

LONG Dsp_Lock() 

Dieser Aufruf ist so ’ne Art Semaphor, sie ermöglicht es einem 
Programm herauszufinden, ob der DSP gerade von einer anderen 
Applikation benutzt wird. 

Rückgabe: 0 = DSP frei 

-1 = DSP benutzt 


XBIOS 105 

VOID Dsp_Unlock() 

Um den DSP für andere Applikationen wieder frei zu geben, nach 
dem man ihn zuvor mit ’Dsp_Lock’ gesperrt hat, muß diese Funk¬ 
tion aufgerufen werden 


XBIOS 106 

VOID Dsp_Avaiable(LONG *xavaiable, LONG *yavaiable) 

Gibt Menge des vorhandenen X- und Y-Speichers aus. Da der P 
Speicher den X- und Y-Speicher überlagert, liegen in den unteren 
64*24 Bit des Y-Speichers die DSP Interrupt Vektoren. 

xavaiable , Zeiger auf eine Variable, in die die Menge des 
verfügbaren X Speichers eingetragen wird 

yavaiable , Zeiger auf eine Variable, in die die Menge des 
verfügbaren Y Speichers eingetragen wird 
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XBIOS 107 

LONG Dsp_Reserve(LONG xreserve, LONG yreserve) 

Der angeforderte Speicher sollte die von ’Dsp_Avaiable’ erhaltenen 
Werte nicht übersteigen. Der Speicherbereich wird solange vor 
Überschreiben geschützt, bis der ’Dsp_Reserve’ Aufruf nochmals 
erfolgt. 

xreserve, Menge des zu reservierenden X-Speichers in 
DSP Worten 

yreserve, Menge des zu reservierenden Y-Speichers in 
DSP Worten 

gibt bei erfolgreichem Aufruf 0 zurück 


XBIOS 108 

LONG Dsp_LoadProg(LONG *file, WORD ability, LONG *buffer) 

Lädt Programme im ”.LOD" Format, wandelt sie vom ASCII ins bi¬ 
när Format und führt sie in den durch ’Dsp_Reserve" reservierten 
Bereich im DSP aus. 

file , Zeiger auf den Dateinamen 
ability , Kennzeichnung des Programms 

buffer, Zeiger auf Zwischenspeicher für den generierten DSP Code 

die Größe des Speicherbereichs, die auf den Puffer zeigt, berech¬ 
net sich wie folgt: 

wort = Dsp Wortgröße 

anz = Anzahl der Programm und Datenworte in der “.LOD" Datei 
block = Anzahl der Blöcke in der ".LOD" Datei 

wort*(anz+(wort*block)) 
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Gibt eine Null zurück, falls der Aufruf erfolgreich verlaufen ist, an¬ 
sonsten -1. 

XBIOS 109 

VOID Dsp_ExecProg( LONG *codeptr, LONG codesize, 

WORD ability) 

Ähnlich wie ’Dsp_LoadProg’, mit dem Unterschied, daß das Pro¬ 
gramm nicht geladen und ins Binär-Format umgewandelt werden 
muß, sondern in dieser Form schon im Speicher erwartet wird. 

codeptr , Zeiger auf ein DSP Programm im Binär-Format 

codesize , Länge des Programms 

ability , Kennzeichnung des Programms 


XBIOS 110 

VOID Dsp_ExecBoot(LONG *codeptr, LONG codesize, WORD ability) 

Diese Funktion führt einen Reset im DSP durch, lädt ein Programm 
in das interne 512 Wort Breite RAM des DSP und startet es. Laut 
ATARI sollte dieser Aufruf nur von Debuggern oder ähnl. Program¬ 
men verwendet werden, andere Programme sollten nicht den DSP 
komplett für sich in Anspruch nehmen. 

codeptr , Zeiger auf ein DSP Programm im Binär-Format 
codesize , Länge des Programms <512 DSP Worte 
ability , Kennzeichnung des Programms 
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XBIOS 111 

Dieser Aufruf lädt ".LOD" Dateien und wandelt sie ins Binär-Format 
um. 

LONG Dsp_LodToBinary(LONG *file, LONG ‘codeptr) 

file , Zeiger auf den Dateinamen 

codeptr, Zeiger auf den Code im ".LOD" ASCII-Format 

Der Speicherbereich auf den ’codeptr’ zeigt, muß groß genug ge¬ 
wählt werden, um das DSP Programm im Binär-Format aufnehmen 
zu können. 

Die Funktion liefert die Größe des Programms im Binär-Format zu¬ 
rück, im Fehlerfall eine negative Zahl. 


XBIOS 112 

VOID Dsp_TriggerHC(WORD vector) 

Starten einer Routine via Host Command Vektor des DSP. Nur die 
Vektoren $13 und $14 sind frei, alle anderen sind durch das Be¬ 
triebssystem belegt und werden bei jedem Programmstart im DSP 
wieder initialisiert (siehe 7.2.2). 

vector, Host Command Vektor des DSP ($13 u. $14) 


XBIOS 113 

WORD Dsp_RequestUniqueAbility() 

Gibt eine einmalige 16 Bit Nummer als Kennzeichnung (ability) im 
DSP zurück, diese kann man dann zum Laden eines Programms in 
den DSP benuzen. Bei einem erneuten Versuch, das DSP Pro- 
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gramm zu starten, braucht man dann nur zu testen, ob es noch 
vorhanden ist. Das macht es unnötig, vor jedem Start einer Routine 
oder Programms im DSP diese nachzuladen. 

XBIOS 114 

WORD Dsp_GetProgAbility() 

Gibt zurück, welche Kennzeichnung (ability) das Programm, das 
sich im Moment im DSP befindet, besitzt. 

XBIOS 115 

VOID Dsp_Flushroutines() 

Löscht Unteroutinen aus dem DSP Speicher, sollte nur wenn unbe¬ 
dingt nötig benutzt werden, um, wenn mehrere Prozesse den DSP 
benutzen, das zeitraubende dauernde Neueinladen von Unterrouti¬ 
nen zu vermeiden. 

XBIOS 116 

WORD Dsp_LoadSubroutine(LONG *ptr, LONG size, WORD ability) 

Lädt eine Unterroutine in den DSP Speicher, die darin resident ver¬ 
bleibt. Erst wenn alle Plätze für Unterroutinen belegt sind, kann es 
mit einer anderen Routine überschrieben werden. Auch kann man 
eine DSP-Unterroutine mit Dsp_FlushSubroutine aus dem Speicher 
entfernen. 

ptr , Zeiger auf den Code im Binär-Format 
size , Länge der Routine in DSP Worten 
ability , Kennzeichnung der Routine 

Gibt ein positives Handle zurück, wenn die Routine erfolgreich im 
Speicher untergebracht, Null wenn sie nicht installiert wurde. 
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XBIOS 117 

WORD Dsp_lnqSubrAbility(WORD ability) 

Gibt das Handle der jeweiligen Unterroutine zurück. Damit ein Pro¬ 
zess Unterroutinen benutzen kann, die er selbst gar nicht installiert 
hat, z.B. Unterroutinen, deren Kennzeichnung ATARI festgelegt 
hat, also eine Art Library-Funktion, die der Prozess sonst selbst 
geladen hätte. 

ability, Kennzeichnung der Routine 


XBIOS 118 

WORD Dsp_RunSubroutine(WORD handle) 

Startet im DSP Speicher befindliche Unterroutine. 

handle, Wert den man z.B. von ’Dsp_LoadSubroutine’ zurück be¬ 
kommt 

Eine Null gibt an, daß die Unterroutine erfolgreich gestartet wurde, 
ein negativer Wert, daß ein Fehler aufgetreten ist. 


XBIOS 119 

WORD Dsp_HfO(WORD flag) 

Ändern von Bit 3 im Host Status Register (HSR) des DSP. 
flag, 0 = HFO löschen, 1 = HFO setzen, -1 = nicht ändern 
Gibt alten Inhalt zurück. 
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XBIOS 120 

WORD Dsp_Hf1 (WORD flag) 

Ändern von Bit 4 im Host Status Register (HSR) des DSP. 
flag, 0 = HF1 löschen, 1 = HF1 setzen, -1 = nicht ändern 
Gibt alten Inhalt zurück. 

XBIOS 121 

WORD Dsp_Hf2(WORD flag) 

Ändern von Bit 3 im Host Control Register (HCR) des DSP. 
flag, 0 = HF2 löschen, 1 = HF2 setzen, -1 = nicht ändern 
Gibt alten Inhalt zurück. 

XBIOS 122 

WORD Dsp_Hf3(WORD flag) 

Ändern von Bit 4 im Host Control Register (HCR) des DSP. 
flag, 0 = HF3 löschen, 1 = HF3 setzen, -1 = nicht ändern 
Gibt alten Inhalt zurück. 

XBIOS 125 

BYTE Dsp_HStat() 

Gibt den Inhalt des Interrupt Status Registers (ISR) des DSP zu¬ 
rück. Gibt an, ob der Host Port zum Senden oder Empfangen von 
Daten bereit ist. 
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7.5 Ideen zum DSP 

Wie oben schon erwähnt, hatte ich den Falcon nur sehr kurze Zeit, 
ich konnte mich zwar recht ausgiebig mit ihm beschäftigen, aber 
der DSP ist einfach zu komplex, um alles mit ihm Mögliche in kur¬ 
zer Zeit durchspielen zu können. Also hier noch einige Ideen zum 
Nutzen des Falcon für Spieleprogrammierer. 

Da der DSP im Falcon030 schneller als die CPU ist, könnte ich mir 
gut vorstellen, daß einige Programmierer auf die Idee kommen, re¬ 
chenintensive Spiele komplett im DSP laufen zu lassen und nur die 
audiovisuelle Präsentation auf dem Rest des System laufen zu las¬ 
sen. 

Auch müßte es meiner Meinung nach möglich sein, aus dem Falcon 
mit Hilfe des DSP, achtstimmige Samples mit variabler Abspielfre¬ 
quenz auf dem CODEC D/A Wandler auszugeben. Dazu muß man 
per DMA dem DSP die Sounds häppchenweise zum Zusammenmi¬ 
schen übergeben, der speichert diese zwischen und mischt sie im 
angemessenen Frequenzverhältnis. 

Ebenfalls könnte man per DMA gepackte Bilddaten in den DSP la¬ 
den und Stück für Stück entpackt und per DMA in einen anderen 
Speicherbereich übertragen, während der User auf dem Bildschirm 
"fröhlich" Weiterarbeiten kann. Aber nicht nur entpacken kann der 
DSP, auch das Manipulieren und Interpolieren von Bilddaten könnte 
man den DSP erledigen lassen. 

Auch einen mathematischen Coprozessor könnte man den DSP 
emulieren lassen und via LINE F die Coprozessor Befehle emulie¬ 
ren. Das wäre dann zwar, durch die Zeit, die bei den LINE F Ex- 
ceptions verloren gehen, nicht besonders schnell, aber immer noch 
schneller als wenn der 68030 mit 16MHz die Emulation vornehmen 
sollte. 

Wichtig! ist, der DSP ist ein eigenes System mit eigenem Bus, d.h. 
alles was an Code im DSP läuft, läuft volkommen unabhängig von 
Busmastern auf dem 68030 Daten/Adressbus. Selbst wenn Floppy 
oder SCSI DMA läuft, kann der DSP (falls er kein Datentransfer 
auf/vom System Bus stattfindet) ungestört Weiterarbeiten. 
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Anhang A Optimierung 

Bei Optimierungen muß man höllisch aufpassen, da die Programme 
danach meist viel schlechter lesbar sind. Man sollte daher nur sehr 
zeitkritische Programmteile auf Geschwindigkeit optimieren und nur 
wirklich speicherplatzkritische auf Länge. 

A.1 Hochsprachen Optimierung 

A.1.1 Wo ein ’IF’ ist, darf auch ein ’ELSE’ sein 

Ein häufiger Fehler von Programmieranfängern ist, daß sie bei 
mehreren ausschließenden ’IF’ Abfragen diese untereinander set¬ 
zen und nicht nach der ersten Abrage die restlichen in ’ELSE’ 
Zweige. 

Beipiel: FALSCH !!! 

Geht alle Bedingungen durch, obwohl möglichenweise schon die er¬ 
ste die wahre Aussage ist! 

IF x%=4 AND y%=1 
PRINT "TOTAL“ 

ENDIF 

IF x%=3 AND y%=4 
PRINT "NOJO" 

ENDIF 

IF x%=8 AND y%=3 
PRINT "OJOJ“ 

ENDIF 
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Beispiel: RICHTIG !!! 

IF x%=4 AND y%=1 
PRINT “TOTAL“ 

ELSE IF x%=3 AND y%=4 
PRINT "NOJO" 

ELSE IF x%=8 AND y%=3 
PRINT "OJOJ" 

ENDIF 

Im zweiten Fall werden nach einer richtigen Bedingung die restli¬ 
chen Vergleiche gar nicht mehr abgefragt. Wenn man die Verglei¬ 
che dann noch nach möglicher Häufigkeit ordnet, d.h. als allerer¬ 
stes die Bedingung abfragen, die öfter als die anderen kommen 
könnte und den Rest in wahrscheinlicher nach unwahrscheinlicher 
ordnet, kann man an zeitkritischen Stellen z.B. Kollision einiges an 
Rechenzeit sparen. 


A.1.2 Es müssen nicht immer Fließkommazahlen sein ! 

Bei Spielen z.B. Simulationen werden oft irgendwelche Formeln mit 
vielen “komplizierten" Ausdrücken berechnet, die dann aber meist 
nur pixelgenau grafisch dargestellt werden. In solchen Fällen hat es 
sich in Assembler als vorteilhaft erwiesen, mit geringerer Genauig¬ 
keit zu rechnen z.B Langworten und das niederwertige Wort als 
Nachkommastellen und das höherwertige als ganze Zahlen zu nut¬ 
zen. So kann man sich dann die komplizierte Fließkommaroutinen 
sparen. 

In Hochsprachen kann man sich mit einer ähnlichen Technik in vie¬ 
len Fällen die Fließkommazahlen sparen. Man braucht z.B. Zahlen 
mit einer Nachkommastelle, dann nimmt man die Werte mit denen 
man rechnen möchte, multipliziert sie mal zehn und überträgt diese 
z.B. in 32 Bit Variablen. Der Wert vor dem Komma kann dann im¬ 
mer noch bis über 200 Millionen groß werden, was für die meisten 
Fälle genügen dürfte. Allerdings gibt es bestimmte Regeln die man 
bei der Benutzung dieser Zahlen beachten muß. 
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Addieren: 
kein Proplem 
Multiplizieren: 

Wenn 2 gewandelte Zahlen multipliziert werden, muß das Ergebnis 
durch den Faktor geteilt werden, mit dem sie umgewandelt wurden. 

Beispiel: 

n=100.23 

n%=n*100 ! also 10023 


k=450.33 

k%=k*100! also 45033 

'nimmt man k%*2, kann man das Ergebnis am Ende wieder durch 
100 teilen und bekommt dann k*2 

k%=k%*2 !k%=90066 

k=k%/100 !k=900,66 also genau 2*k 

'allerdings wenn man k% * n% nimmt 

k%=k% * n% ! 90066*10023=902731518 
’ Wenn man das durch 100 teilt, hat man eben dann noch nicht 
’ das Ergebnis 

k=k%/10000 ! das ergibt 90273.1518, also genau k*n 


331 



Spiele selbst programmieren 


A.1.3 Addieren ist oftmals besser als Multipizieren ! 

Beim Ausrechnen einer Formel per Hand ist es im Prinzip egal, ob 
der Taschenrechner eine Zehntelsekunde schneller oder langsam- 
mer "mit dem Ergebnis herausrückt'', da in diesem Fall der Mensch 
das langsamste Glied in der Kette ist und somit jeder zusätzliche 
Denkprozeß die Zeit, die zum Errechnen eines Ergebnisses benö¬ 
tigt, erhöhen würde. Bei einem Programm ist das umgekehrt, denn 
wenn der Algorithmus fertig ist, läßt jede zusätzliche Optimierung 
(also Denkprozeß des Programmierers) das Programm etwas 
schneller das Ziel (also die Lösung) erreichen. 

Hier ein Beispiel für Optimierung: 


C=2*B 

D=3*B 

eine Optimierung wäre in diesem Fall, 


C=2*B 

D=C+B 


da eine Addition von Rechnern in der Regel schneller durchgeführt 
wird als eine Multiplikation. 

Nicht immer läßt sich eine Optimierung so leicht erkennen wie in 
diesem Fall und es ist auch nicht immer sinnvoll, bis zur letzten 
Konsequenz einen Algorithmus zu optimieren, wenn ein Programm 
eh schon schnell genug ist und die Lesbarkeit des Programms nicht 
mehr gewährleistet ist (das ist bei Spielen aber nicht so wichtig, da 
Spielprogramme nur in seltenen Fällen von anderen Programmie¬ 
rern gewartet (d.h. Fehler im veröffentlichten Programm ausbes¬ 
sern) werden. 
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A.1.4 Erst rechnen, dann vergleichen 

Vergleiche kommen sehr häufig in Programmen vor und oft muß 
man ein und denselben Ausdruck mit vielen anderen Ausdrücken 
vergleichen. Wenn der Ausdruck jedoch eine Formel ist, sollte man 
sich überlegen, ob man nicht erst rechen und dann vergleichen 
sollte. 

Beispiel: 

IF 2*(x+z)<2*n+4 or 2*(x+z)<100 
PRINT "ZIP ZIP BRRRR" 

ENDIF 

schneller! 

k=2*(x+z) 

IF k<2*n+4 or k<100 
PRINT "ZIP ZIP BRRRR" 

ENDIF 


333 



Spiele selbst programmieren 


A.2 Assembler Optimierung 

Assembler ist die Programmiersprache, in der man die schnellsten 
Programme schreiben kann, aber die Betonung liegt in diesem Fall 
auf kann. Man kann in Assembler auch Programme schreiben, die 
langsamer sind als die compilierte Hochsprache. 

Beispiel 1 

Das Füllen des Stacks mit Parametern: 

move.w #1 ,-(SP) 
move.w #34,-(SP) 

kann optimiert werden durch 

move.l #$340001,-(SP); 1 Wort weniger 
oder 

pea $340001 ; 1 Wort weniger 

falls das zu übertragene Langwort nur noch Wortgröße hat 
move.w #1234,-(SP) 

clr.w -(SP) ; ist scheller wie move.w #0,-(SP) 

kann optimiert werden durch 

pea 1234.W ; 2 Worte weniger 

Beispiel 2 

Bereinigen des Stacks: 
add.l #4,SP 

schneller 

addq.l #4,SP ;soweit ist es noch offensichtlich 
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aber 

add.l #12,SP 

4 Taktzyklen schneller 
lea 12(SP),SP 

Beispiel 3 

Um ein Bit nach links schieben: 
Isl.l #1,D0 

schneller 
add.l DO,DO 

Löschen von Registern: 
clr.l DO 

kann optimiert werden durch 

sub.l DO,DO ; schneller! 


Generell gilt, je weniger Zugriffe auf den Speicher desto schneller. 
Das heißt nichts anderes, als daß man so viel Daten wie möglich in 
den Registern halten sollte (davon profitieren ja auch die RISC 
Prozessoren). Oft benutzte Daten in Registern halten, da jeder 
Speicherzugriff längeren Code erzeugt und, wie oben schon er¬ 
wähnt, länger dauert. 

Wenn es schnell gehen soll, vermeidet man besser Schleifen und 
führt die Befehle mit den einzelnen Parametern hintereinander aus. 
Es fallen so die Sprünge und Vergleiche weg. Übrigens das funk¬ 
tioniert auch in Hochsprachen (unrolling LOOPS). 
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Anhang B 

Quellen und weiterführende Literatur 

Bücher: 

Jankowski,Rabich,Reschke:Atari Profibuch ST-STE-TT 
SYBEX, Düsseldorf 1987/88/91/92 ISBN 3-88745-888-5 

Das Standardwerk für Programmierer auf dem ATARI. 

Klein,Thiel:i860 Mikroprozessor der Superklasse 
Francis, München 1991 ISBN 3-7723-4191-8 

Man erfährt darin auch einiges überden 68040 und Prozessoren schlechthin. 

Williams:68030 assembly language reference 
Addison Wesley, USA 1989 ISBN 0-201-08876-2 

Komplette Einführung in die 68000 bis 68030 und 68881/2 Prozessoren, auf jeden 
Fall empfehlenswert. 

Computer graphics: principles and practice 

von James F Foley, van Dam, Feiner, Huges 2nd Edition 

Addison Wesley, ISBN 0-201-12110-7 

Enthält Informationen über Vektorgrafik, Raytracing u.v.m. Auch ein Standard¬ 
werk! 


Mader: Einführung in Forth 83 

Heim, Darmstadt 1989 ISBN 3-923250-69-X 

Gut für Anfänger, auch wenn sie nicht unbedingt Forth programmieren wollen. 

DSP 56000/56001 User’s Manual 
MOTOROLA 1990 

Für Leute, die mehr über den DSP wissen wollen. 


337 




Spiele selbst programmieren 


MC 68040, 32Bit Microprocessors User’s Manual 
MOTOROLA 1989 

Der Falcon040 kommt (hoffentlich) bestimmt! 

Peter Wollschlaeger:Atari-ST-Assembler Buch 

Markt & Technik, Haar bei München 1987 ISBN 3-89090-467-X 

Gut verständliche Einführung in 68000 Assembler, für Anfänger empfehlenswert. 

Martin Pohl, Holger Eriksdotar: Die wunderbare Welt der 
Grafikformate 

Wolfram’s Fachverlag, ISBN 3-925328-05-X 

Zeitschriften: ST COMPUTER - Heim Verlag 

Div. Ausgaben von TOS - ICP Verlag 
ST Magazin - Markt&Technik bzw. AWi Verlag 
CHIP Special, Animation auf dem PC 

Dokumentation von ATARI: 

Falcon030 Developer Documentation vom 1 .Oktober 1992 
THE TT030 COMPANION 

anderes: 

Anleitung zu NoiseTracker v. 1.1 
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Anhang C 

Inhalt der Diskette! 

Der Inhalt der Diskette kann sich je nach Auflage ändern, auf ihr 
befinden sich aber Dateien, die sich nicht ändern ! 

INHALT.TXT , Inhaltsangabe der Diskette 
FEHLER.TXT, bekannte Fehler des Buches 

und einige Files mit dem Kennzeichner ’.TOS’ und den Namen 
’KAP’ gefolgt von ’A’ oder ’B’ und einer Kapitelnummer. Diese Files 
sind selfextracting, d.h. sie entpacken sich selbst. Man muß diese 
Files nur je auf eine extra Diskette kopieren und starten, dann wer¬ 
den aus den jeweiligen ’.TOS“ Programmen die Dateien (Listings, 
Programme etc.) zum jeweiligen Kapitel. 
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Nachwort: 

"Zu Risiken und Nebenwirkungen fragen Sie Ihren Arzt oder Apotheker." 

Nun, über ein Jahr habe ich für dieses Buch gebraucht (ich mußte 
ja zwischendurch noch studieren). Ich hoffe, mein Ziel, zu zeigen 
was in den ATARI Computern steckt und wie man dessen Resour- 
cen richtig (!) nutzt, habe ich erreicht. Aber das wird wohl erst die 
Resonanz auf mein Buch zeigen, das mein Debüt, was Bücher¬ 
schreiben betrifft, ist. 

Der Falcon030 hat mich sozusagen kalt erwischt, ich habe trotz¬ 
dem alle möglichen Informationen gesammelt und in dieses Buch 
mit aufgenommen, so daß dieses Buch für den, der auf dem Falcon 
Spiele programmiert, eine Fundgrube sein wird (nehme ich doch 
stark an !). 

Auf dem TT ist mehr machbar als man denkt. Bitte, liebe Spiele¬ 
programmierer, schenkt diesem Gerät die Beachtung, die ihm ge¬ 
bührt. 

"Juhu, mein erstes Buch ist fertig ! (endlich)" 

Kritik und Anregungen bitte an den Verlag, der diese 
an mich weiterreichen wird ! 

"Geldwünsche und/oder Drohungen sinnlos, habe selbst nichts ! " 


Beantwortet werden nur Briefe von weiblichen "Fans" oder Post mit beige¬ 
fügtem, frankiertem und an sich selbst adressierten Rückum¬ 
schlag. 

oder über E - MAIL 

s=Pollack; ou=rz; p=fh-frankfurt; a=dbp; c=de 

P.S. Jetzt programmiert bitte viele tolle Spiele für Euren ATARI!!! 
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Stichwortverzeichnis 


+/- Tasten 

282 

<= 

17 

<> 

17 

>= 

17 

16 Bit Addierer 

253, 256 

16 MHz Speeder 

121 

200 Hz 

208 

200Hz Timer 

68 

50/60 Hz Umschaltung 

26 

68000 

76 

68010 

76, 171 

68020 

76, 97 

68030 

76, 97 

68040 

76, 97 

68060 

76 

A/D 

225 

A7 

77 

ability 313,322ff 

Absolute Adressierung 

307 

Absolute Adr.-Short Addr. 308 

Access Error Stack Frame126 

ACIA 193,197,208,214 

ACIAS 

192 

Action Spiele 

102 

Actionadventures 

101 

Active Edge Register 

194,204 

ADC 

261 

ADCINPUT 

256 

add 

19, 334f 

ADDERIN 

256 

Additive Synthese 

227, 231 

addq 

87, 334 

Adress Register indirekt 306 


Adress Register indirekt mit 
Offset Register als Index 307 


Adress Register indirekt mit 
postdecrement 306 

Adress Register indirekt mit 
postdecrement Offset Reg.306 
Adress Register indirekt mit 
postincrement 306 

Adress Register indirekt mit 
postincrement Offset Reg. 306 
Adress Register indirekt 
predekrement 307 

Adress+Data Bits 266 

Adressregister 76 

AEOI 198 

AES 129 

AES10 129 

AES 91 129 

AGU 303 

Akkumulatoren 304 

Algorithmus 11 

ALU 303 

Alyssa 168 

Amigas 128 

Amplitude 59,222 

Analog 227f 

AND 29 

ANDI 123 

Animation 44,48 

ARABELLA 174 

Argon 4 40 

AS 227 

ASCI 127 

Assemblercode 75 

B.I.G. D.E.M.O 169 

Ballerspiele 102 

Bconout 214 

Beat 247 

Bildsynchronisation 26 
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Bildwiederholfrequenz 177 

Common Commands 

283 

BIOS 3 

214 

Compiler 

lOf 

Bit 

8 

Cookie 

131 

Bitmap 

25 

Cookies 

63 

Bitplane 

24 

Copper 

191 

Blitmode 

189 

Copy Raster, Opaque 

182 

Blftter 

181,208 

CPU 

7 

BMHD 

296 

CPU Performance 

105 

BMOVE 

28, 46, 108 

CUT OFF 

230 

BODO 

30 



BODY 

297 

D/A Wandler 

228, 248 

Box 

13 

DAC 

261 

Breath Controller 

280 

Das Skew Register 

186 

buffoper 

259 

Data Direction Reg. 

195,204 

buffptr 

263 

Data Entry 

281 

Bus Fehler 

126 

Datenregister 

76, 303 

bus snooping 

128 

DC 

226 

BUSY 

186 

DCA 

226 



DCF 

226 

CAAR 

96 

DCO 

226 

Cache 

127 

DE 

169, 213 

Caches 

96 

Default Stack Frame 

125 

CACR 

96 

Degas Elite 

290, 292 

CALL 

69 

Destination Adress 

184 

Carebears 

232 

Destination X increment 184 

Carry Flag 

78 

devconnect 

261 

CCR 

78 

Device 

252 

CD 

224 

Digitalisieren 

224 

centry_size 

293 

Display Enable 

208f, 213 

Channel Mode 

282 

Division by Zero 

126 

Circle 

12 

DMA 192,203,209,241,252,261 

clr 

79, 86, 334f 

DMA Input 

252 

CMAP 

297 

DMA Output 

252 

cmapjen 

293 

DMA Sound 

193, 195 

cmap_origin 

293 

DMA Subsystem 

241 

cmap_type 

293 

Dosound 

240 

CMP 

94 

Dreieck 

226 

CODEC 

252f, 261,263 

DSP 105,252,299,305 
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DSP 56000/1 

299 

Echtfarbauflösung 

187 

DSP 56001 

272, 299 

Editor 

10 

DSPRECV 

261 

EgetPalette 

156 

dsptristate 

260 

EgetShift 

155 

DSPXMIT 

261 

Ein/Ausschalter 

282 

Dsp_Avaiable 

320 

ELECTRA 

232 

Dsp_BlkBytes 

318 

Elektronenwolken 

221 

Dsp_BlkHandShake 

314 

ELSE 

329 

Dsp_BlkUnpacked 

315 

ENABLE Bit 

245 

Dsp_BlkWords 

317 

Entwicklungsumgebung 

10 

Dsp_DoBlock 

314 

Envelope 

227 

Dsp_ExecBoot 

313, 322 

EOI 

200 

Dsp_ExecProg 

322 

EQU 

85 

Dsp_Flushroutines 

324 

EsetBank 

155 

Dsp_FlushSubroutine 

324 

EsetColor 

155 

Dsp_GetProgAbility 

324 

EsetPalette 

156 

Dsp_GetWordSize 

317 

EsetShift 

154 

Dsp HfO 

325 

ET4000 

174 

Dsp_Hf1 

326 

etv_timer 

61 

Dsp_Hf2 

326 

EVENT COUNT 

72, 170 

Dsp_Hf3 

326 

Event Count Mode 

246 

Dsp_HStat 

326 

EVERY 

61 

Dsp_lnqSubrAbility 

325 

EVERY STOP 

62 

DspJnStream 

315 

Exception 

130 

Dsp_IOStream 

316 

Exception Stack Frame 

126 

Dsp_LoadProg 

321 

eXtented Flag 

78 

Dsp_LoadSubroutine 

324 

EXTINP 

261 

Dsp_Lock 

320 

EXTOUT 

261 

Dsp_LodToBinary 

323 



Dsp_MultBlocks 

319 

Falcon 40 

96 

Dsp_OutStream 

316 

Falcon Shift-Mode-Reg. 

175 

Dsp_Removelnterrupt 

317 

Farbpalette 

179 

Dsp_RequestUniqueAbility 323 

FIFO 241,247, 252 

Dsp_Reserve 

321 

Filter 

222 

Dsp_RunSubroutine 

325 

Flags 

309 

Dsp_SetVectors 

318 

Flugsimulator 

203 

Dsp_T riggerHC 

323 

FM 

227, 229 

Dsp_Unlock 

320 

FORM 

296 


343 



Spiele selbst programmieren 


Form der Hüllkurve 238 

Format Code 125 

Format einer Note 270 

FORM_DIAL 65 

Forth 10 

FORTRAN 10 

FPU 131 

Frame Address Counter 243 
Frame Endadresse 244 

Frame Startadresse 243 

Frequenz 58 

Frequenzmodulation 227 

Füllmuster 182 

Fuß Peda 281 

FXSR 186 

General Instument 232 

Genlocks 122 

Geschwindigkeit 67 

GET 185 

Getrez 153 

GFA-BASIC 10 

Giaccess 239 

GLUE 169 

gpio 260 

Gpip Data Register 193,203 
Grafik Adventures 101 

Grafik/Text Adventures 100 

Halftone Operation Reg. 185 
Halftone-Ram 182 

HAM MODUS 107 

Handshake 252 

Handshaking 262 

Hardware Scrolling 160 

Hardwarescrollen 113 

Hardwarescrolling 108, 151 
Hardwarescrollings 165 


Harmonische 

231 

HBL 

171 

HIGH ADDRESS ALU 

303 

Highscore 

55 

Hintergrundes 

24 

HOG 

186, 188 

Horizontal Blank links 

176 

Horizontal Blank rechts 

176 

Horizontal Sync Start 

177 

Horizontale Position 

175 

Horizontales Scrolling 

111 

HSYNC 

169 

Hüllkurve 

227 

Hyper-Mono-Mode 

150 

Hypermono 

154f 

I/O Port A,B 

238 

17 248, 258, 264 

identjen 

293 

IFF 168, 290, 296 

IKBD 61, 189, 197, 208, 214f 

Ikbdws 

214 

image_width 

293 

image_xorg 

293 

image yorg 

293 

IMG 

290 

Implicrt Reference 

308 

Infocom Adventures 

99 

Interlace 

157 

Interpreter 

10 

Interpretersprache 

10 

IR Enable Register A 

204 

IR Enable Register B 

197, 205 

IR In Service Reg. A 

198, 205 

IR in Service Reg. B 

199, 205 

Interrupt Mask Register 

211 

IR Mask Register A 

199, 206 

IR Mask Register B 

199, 206 
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IR Pending Reg. A 

198, 205 

LOW LEVEL I/O 

106 

IR Pending Reg. B 

198, 205 

Isl 

335 

IR Vektor Register 

200, 206 

LTATTEN 

255 

ISP 

77 

LTGAIN 

255 



LZW 

290 

Jdisint 

210 



Jenabit 

211 

MAC 

128 

Joystick 53, 197, 214f, 217 

Macintosh 

140 

JPEG 

289 

mage_height 

293 



Mask-Register 

267 

Kbaud 

273 

Maske 

24, 37, 45 

Kbdvbase 

215 

Masken - Register 

183 

Keyboard 

192, 197 

Matrix 

256 

Kollision 

49 

Maus 

192 

Konstanten Adressierung 307 

MFP 

61, 192 

Konst. Adr.-Short Byte 

307 

MFP 68901 

192 

Kopfhörer 

252 

MFP 17 

263 

Kreise 

12 

Mfpint 

211 



Microwire 

265 

LAN 

203 

MIDI 193,197,208,215,273 

Lautstärke 

59 

MIDI Schnittstelle 

273 

Lautstärke f. d. Tonkanäle 237 

Mikrofon 

252 

lea 

335 

MIXER und I/O 

236 

Leerschleifen 

67 

MMU 

121, 169 

LEVEL 16 

169 

MOD 

250, 269 

LFO 

222,226 

Modeplayer 

251 

Light - Pen 

218 

Modula 

10 

Light Pen 

217 

Modulation 

280 

LineA 130,187,189 

Modulations Rad 

280 

Line F 

126, 131 

Monitor Typ 

176 

Line Number 

186 

MONO 

274 

Linien 

12 

Monochrome Detect 

196 

Linker 

75 

monophoner Aftertouch 278 

Linker Rand 

177 

mon_type 

158 

LMC1992 

265, 267 

Mouse 

197 

locksnd 

254 

Mousek 

14 

Logbase 

69, 153 

Mousex 

14 

LOW ADDRESS ALU 

303 

Mousey 

14 
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move 79ff, 86f, 98, 125 

MOVEC 96 

movem 109, 115 

MSP 77 

MULTI - TOS 65 

Multi TOS 39,134 

Multitos 130 

Musik 57 

Negativ Flag 78 

Neochrome 291 

NEOCROME 30 

NEOCROME MASTER 30 

NEXT 128, 140 

NFSR 186 

NOTE an 276 

Noten 60 

nvbls 161 

Oberer Rand 178 

Oberwellen 231 

Offgibit 239 

Oktave 58 

OMNI 274 

Ongibit 239 

Operation Register 185 

OR 118 

Oszillator 226 

Oszillatoren 228f 

Overflow Flag 78 

Paddels 218 

Paddies 217 

page flipping 23 

parallel 60 

PASCAL 10 

PC 83, 128 

PD 227 


PDL 

41 

pea 

334 

Pellipse 

12 

Periodend. der Hüllkurve 

237 

Phase Distortion 

227 

Physbase 

152 

Pitch Bend 

277 

Pixel Höhe/Breite 

178 

pixel size 

293 

POLY 

274 

polyphoner Aftertouch 

279 

Portamento Time 

281 

prescale 

264 

Procedueren 

40 

Programm 

11 

Programm Change 

278 

Programm Kontroll Reg. 

304 

PSG 232,256 

PUT 

185 

RAM 

8 

RC 

228 

RCALL 

72 

RC_COPY 

29, 185 

Real Time Information 

284 

Rechteck 

226 

Rechter Rand 

177 

Register des PSG 

233 

Register direkt 

305 

Reloziertabelle 

83 

Resonanz 

223 

Ring-Modulation 

227 

Ringmodulation 

230 

RM 

227 

ROM 

7 

RTATTEN 

255 

RTGAIN 

255 

RTS 

215 
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S/N 

224 

Sample & Hold-Mode 

150 

Sample Dump Standard 

285 

Sampling 

224 

savptr 

264 

scale factor 

98 

SCC 

203 

SCC DMA 

209 

Schleifen 

15 

Schußknopf 

217 

Schwingungen 

221 

SCI-Port 

301 

SCSI 127,203,209 

SEOI 

199 

setbuffer 

257 

Setcolor 

154 

setexec 

161 

setinterupt 

258 

setmode 

257 

setmontracks 

258 

Setpalette 

154 

SETPRESCALE 

257 

Setscreen 

152f 

settracks 254,258 

Shrfter 

145 

Short Jump Address 

308 

Sierra 

101 

Signalprozessor 

252 

Signalprozesssor 

299 

Sinus 

226 

Skew 

186 

Smear Modus 

154f 

Smudge 

186 

sndstatus 

262 

SOUND 

62 

Sound DMA - Control 

242 

Sound Enable Bit 

247 

Sound Mode Control 

244 


soundcmd 255 

Source X Increment 182 

Source Y increment 183 

Source-Adress-Register 183 

SP 86 

SPECIAL 307 

Spectrum 512 290 

Speicher 134 

Sprite 23,45 

SSP 77 

ST kompatible Farbreg. 147 

ST Shift-Mode-Register 148 

Stack Format 126 

STAD 290 

Stereoausgänge 222 

sub 21,335 

Superexec 91 

Supervisormode 88 

swap 116,249 

Sync Mode Falcon 178 

Sync-Mode-Register 147 

Syncmode Register 122 

Syncronisation 284 

Syncscrolling 173 

Synthesizer 227 

System Exclusive 284 

Systemvariable 28 

TARGA 293 

Tastatur 193 

Tastenabfrage 54 

TEX 168 

Text Adventures 99 

Timer 61, 124 

Timer A 192f, 246, 258, 263f 
Timer A Control Reg. 200, 206 
Timer A Data Register 207 

Timer B 100, 195, 208f 
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Timer B Control Reg. 201,206 


Timer B Data Reg. 202, 207 

Timer C 197,208,247 

Timer C Control Register 206 

Timer C Data Reg. 202, 207 

Timer D Data Reg. 202, 207 

Timer Vektor 211 

Tonhöhe 235,270 

TOS 85 

TRAP 87 

TrueColor 36 

TT Farbpalettenregister 151 

TTMFP 212 

TT-Shift-Mode Register 149 

Union 169 

UNION - Demos 112 

unlocksnd 255 

unrolling LOOP 335 

Unterer Rand 178 

USART 203 

User-Mode 88 

USP 78 

Variablen 18 

VBL 27, 165, 247 

VBR 96 

VC 226 

VCA 226 

VCF 226 

VCO 226 

VDI 118,181,187,189 

VDI 109 182 

Vector Basis Register 189 

Vector Offset 126 

Vektortabelle 207f, 215 

Velocity 59, 276 

Verbindungs Matrix 253 


Verbindungsmatrix 

251,261 

vergrößern 

113, 117 

Vertical Sync Start 

178 

Vertikal Blank oben 

177 

Vertikal Blank unten 

177 

VgetRGB 

159 

Vgetsize 

159 

Vibrato 

222, 226 

Video Adress Counter 

145 

Video Basis Register 

145 

virtuelle Bildschirme 

165 

vr_trn_fm 

136 

vr_trn_fm() 

138 

VsetMask 

160 

Vsetmode 

157 

VsetRGB 

159 

VsetSync 

158 

VSYNC 

169 

vt_trn_fm 

137 

WAVE 

62 

Wellenbewegungen 

221 

WINDJJPDATE 

65 

Wings of Death 

181 

Wordbreite 

305 

work_out 

65, 166 

work_out Feld 

20 

X-Count-Register 

184 

XBIOS100 

316 

XBIOS101 

316 

XBIOS102 

317 

XBIOS 103 

317 

XBIOS 104 

320 

XBIOS 105 

320 

XBIOS 106 

320 

XBIOS 107 

321 

XBIOS 108 

321 
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XBIOS 109 

322 

XBIOS110 

313, 322 

XBIOS 111 
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XBIOS 112 
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XBIOS 114 
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XBIOS 115 

324 

XBIOS 116 

324 

XBIOS 117 
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XBIOS 118 

325 

XBIOS 119 

325 

XBIOS 120 

326 

XBIOS 121 

326 

XBIOS 122 

326 

XBIOS 123 

317 

XBIOS 124 

318 

XBIOS 125 

326 

XBIOS 126 

318 

XBIOS 127 

319 

XBIOS 128 

254 

XBIOS 129 

255 

XBIOS 130 

255 

XBIOS 131 

257 

XBIOS 132 

257 

XBIOS 133 

254, 258 

XBIOS 134 

258 

XBIOS 135 

258 

XBIOS 136 

259 

XBIOS 137 

260 

XBIOS 138 

260 

XBIOS 139 

261 

XBIOS 140 

262 

XBIOS 141 

263 

XBIOS 150 

160 

XBIOS 2 

152 

XBIOS 25 

214 

XBIOS 26 

210 

XBIOS 27 

211 


XBIOS 28 

239 

XBIOS 29 

239 

XBIOS 3 

153 

XBIOS 30 

239 

XBIOS 31 

21 Of 

XBIOS 32 

240 

XBIOS 34 

215 

XBIOS 4 

153 

XBIOS 5 

152f 

XBIOS 6 

154 

XBIOS 64 

189 

XBIOS 7 

154 

XBIOS 80 

154 

XBIOS 81 

155 

XBIOS 82 

155 

XBIOS 83 

155 

XBIOS 84 

156 

XBIOS 85 

156 

XBIOS 88 

157 

XBIOS 89 

158 

XBIOS 90 

158 

XBIOS 91 

159 

XBIOS 93 

159 

XBIOS 94 

159 

XBIOS 96 

314 

XBIOS 97 

314 

XBIOS 98 

315 

XBIOS 99 

315 

Xbtimer 

70, 21 Of 

XOR 

21,29 

Y Datenspeicher 

300 

Y-Count-Register 

184 

Y-Speicher 

300 

Yamaha 

71, 173, 232 
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Zeilenrücklauf 

151 

Zeilenwiederholfrequenz 

176 

Zero Flag 

78 

Zufall 

226 

Zwiebelschalen 

42 

_CPU 

133 

Jongframe 

126 

MCH 

133 

_SND 

133 

vblqueue 

161 

_VDO 

133 
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Wichtige Merkmale: 

Wer bisher dem interessierten Anfänger ein Buch zur Spieleprogram¬ 
mierung für den ATARI Rechner nennen sollte war überfragt. Dieses 
Buch beseitigt dieses Manko. Es zeigt dem interessierten Anfänger, 
was er bei der Programmierung seines ersten Spieles beachten sollte 
und erklärt Schritt für Schritt den Aufbau eines Spieles anhand vieler 
Beispiele. Dem Fortgeschrittenen stellt das Buch das entsprechende 
Know-How zur Verfügung, um professionelle Effekte, wie man sie von 
guten Spielen kennt, in seinen eigenen Programmen zu verwenden. 
Für alle Umsteiger von anderen Rechnersystemen hilft es gewohnte 
Effekte auf den Atari zu konvertieren. 

Aus dem Inhalt: 

□ Einführung in BASIC und Assembler 

□ Mehrfarbige Sprites 

□ Ein komplettes Spiel - Aufbau und Programmierung 

□ Kompatible Programmierung von ST/STE/TT/Falcon 030 

□ Programmierung der Grafikhardware 

□ Rasterinterrupts 

□ Soundprogrammierung, PSG, STE/TT/Falcon 030 DMA 

□ Format der AMIGA Soundmodule 

□ Diverse Grafikformate 

□ Nutzung des DSP 56001 bei der Spieleprogammierung 

□ MIDI - Programmierung 

□ und vieles mehr 


ISBN 3-928480-13-8 incl. Diskette 

Bestell-Nr. B-465 
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